feat: add build utilities and SSR renderer to fast-test-harness

[radium-v]

Pull Request

📖 Description

Add build-time utilities and a redesigned SSR renderer to @microsoft/fast-test-harness.

• @microsoft/fast-test-harness:
  • DOM shim (build/dom-shim.ts): Minimal DOM shim that allows FAST Element's css and html tagged templates to execute in Node.js, enabling build-time extraction of styles and templates.
  • Stylesheet generation (build/generate-stylesheets.ts): Extracts compiled FAST ElementStyles modules into plain CSS files for SSR.
  • F-template generation (build/generate-templates.ts): Reverse-engineers compiled FAST ViewTemplate modules back into declarative <f-template> HTML files for the WASM renderer.
  • SSR renderer overhaul (ssr/render.ts): Replaced the simple renderTemplate/renderFixture helpers with a createSSRRenderer() factory that discovers component build artifacts and supports both multi-component packages (Fluent-style) and per-component packages (MAI-style).
  • Server rewrite (server.mjs): Replaced Express with a native Node.js HTTP server, removing the express dependency. Added cheerio for HTML manipulation during SSR fixture rendering.
  • Playwright config updates: CI-aware retries/timeouts, configurable PORT, and updated server command to use the fast-test-harness CLI.
• @microsoft/fast-html:
  • Added ./syntax.js export map entry.
  • Fixed files glob patterns.

👩‍💻 Reviewer Notes

• The createSSRRenderer() factory in ssr/render.ts is the main entry point for SSR testing. It requires @microsoft/fast-build WASM and throws if it's not installed. The render() method falls back to raw entry HTML only if WASM rendering of a specific fixture fails.
• The DOM shim is intentionally minimal — it only implements enough of the DOM API for ElementStyles.toString() and html template compilation to work. It is not a general-purpose DOM emulation.
• @microsoft/fast-build was moved from peerDependencies to dependencies in fast-test-harness since the harness now relies on it directly for build utilities.

📑 Test Plan

The test harness is currently a private package (@microsoft/fast-test-harness) tested locally in downstream component packages. Verification should include running component tests in a consuming package (e.g., Fluent UI Web Components) to confirm the SSR rendering pipeline works end-to-end with the new createSSRRenderer() API.

✅ Checklist

General

• I have included a change request file using $ npm run change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

⏭ Next Steps

• Add unit tests for the build utilities (dom-shim, generate-stylesheets, generate-templates).
• Add integration tests that exercise the createSSRRenderer() factory with sample component fixtures.
• Publish the new @microsoft/fast-test-harness package to npm.
• Update downstream consumers to use the new package for testing.