John Kreitlow

feat(web-components): generate SSR templates and stylesheets into src/ (#36259) ## Previous Behavior SSR template HTML and stylesheet CSS were generated at build time and written only to `dist/`. The output had no presence in `src/`, was never committed, and contributors had no way to inspect the DSD output without running a build. ## New Behavior SSR templates and stylesheets are now generated next to their `*.template.ts` / `*.styles.ts` siblings in `src/` and committed to the repo. This makes the DSD output visible during the WC v3 alpha. `yarn compile` no longer regenerates them; it copies `src/**/*.template.html` and `src/**/*.styles.css` into `dist/esm/`. `yarn generate:ssr` runs the harness's `generateFTemplates` and `generateStylesheets` with `outDir: 'src'` and formats the result with Prettier. `yarn check:ssr` runs the generators against a staging directory and compares the result to `src/` and the working tree. It reports `unchanged`, `created`, `updated`, `stale`, `handEdited`, and `conflicts`, and exits non-zero when stale, hand-edited, or conflicting files appear. `yarn compile` is extended to copy `src/**/*.template.html` and `src/**/*.styles.css` into `dist/esm/` after `tsc`, preserving subdirectory structure. The old `build:ssr`, `build:ssr:styles`, and `build:ssr:templates` scripts were removed.

feat(web-components): add SSR support via Declarative Shadow DOM modules (#36247) ## Previous Behavior `@fluentui/web-components` had no server-side rendering path. Components were defined and rendered only on the client, so SSR frameworks could not pre-render Fluent web components into HTML and hydrate them on load. The e2e tests ran against a custom harness that only covered client-side rendering. ## New Behavior `@fluentui/web-components` now supports SSR via Declarative Shadow DOM, built on `@microsoft/fast-element` and `@microsoft/fast-html`. Every component in the package ships a paired `define-async.ts` / `*.definition-async.ts` module so its template can render on the server and hydrate on the client. The build also emits two new asset types alongside the JS modules, one pair per component (42 of each), exposed through new package subpath exports: - `@fluentui/web-components/<component>/template.html`: declarative HTML template wrapped in `<f-template>`, consumed by `@microsoft/fast-html` to render Declarative Shadow DOM on the server. - `@fluentui/web-components/<component>/styles.css`: plain CSS extracted from the component's styles, importable as a raw stylesheet without pulling in the component's JS. Currently, the SSR templates and styles are generated at build time and placed in the `dist` output, but we may want to provide them as src assets in the future for easier consumption and customization. New test harness modules (`test/src/entry-client.ts`, `test/src/entry-server.ts`) and a `test/ssr.html` entry point template exercise the DSD output end-to-end. The e2e pipeline runs SSR tests after CSR tests. Several components needed template or base adjustments to render correctly under SSR: tooltip (anchor positioning polyfill handling), text-input, textarea, tree, and tree-item. The `theme/set-theme` tests are skipped under SSR. ## Next Steps This PR lays the groundwork for SSR support in `@fluentui/web-components`, but there are still some follow-up tasks to complete: - Update to the latest `@microsoft/fast-element` and remove the `@microsoft/fast-html` dependency, as DSD rendering will be directly supported in FAST in the next major release. - Provide more detailed documentation and examples for using the SSR templates and styles. - Add more comprehensive SSR tests covering edge cases and hydration scenarios.

chore(web-components): Upgrade Fluent Web Components to FAST Element v3 (#36351) # Pull Request ## 📖 Description Upgrade the Fluent Web Components (`@fluentui/web-components`) and Chart Web Components (`@fluentui/chart-web-components`) from FAST Element v2 to v3. The bulk of this change migrates the async (SSR) component definitions away from the `@microsoft/fast-html` `RenderableFASTElement(...).defineAsync(...)` pattern to FAST Element v3's declarative API. Each `*.definition-async.ts` now exports a `declarativeDefinition` built from `declarativeTemplate()` and the `FluentDesignSystem` registry, and each `define-async.ts` registers it with the standard `Element.define(...)` call. This drops the `@microsoft/fast-html` runtime dependency entirely. Supporting changes: - Bump `@microsoft/fast-element` from `^2.0.0` to `^3.0.0` in both `web-components` and `chart-web-components`. - Fix timing bugs and race conditions surfaced by the v3 declarative hydration flow. This is a prerelease-level change for `@fluentui/web-components` and a patch for `@fluentui/chart-web-components`.

chore(web-components): use component tag name constants in playwright tests (#36183) ## Previous Behavior Playwright spec files hardcoded component tag names as string literals (e.g., `'fluent-accordion'`, `'fluent-accordion-item'`). Additionally, the `fastPage` fixture automatically called `setTemplate()` during setup, which meant tests could silently depend on that implicit initialization without expressing their own template requirements. ## New Behavior - All spec files now import `tagName` (and related tag name constants) from each component's `.options.js` module and use those constants for `test.use()`, `document.createElement()`, `element.locator()`, and HTML template strings. - The automatic `fastPage.setTemplate()` call has been removed from the test fixture, so every test must explicitly call `setTemplate()` with the template it needs, making each test's DOM setup self-describing.

fix: update various components and add spec modules (#36191)

refactor(web-components): replace compose() with plain definition objects (#36337) ## Previous Behavior Component definitions across `@fluentui/web-components` and `@fluentui/chart-web-components` were created with the `Element.compose()` API. Each `define.ts` then registered the element by calling `definition.define(FluentDesignSystem.registry)`, and benchmarks imported the composed `definition` directly to register elements. ## New Behavior Each component definition is now a plain `PartialFASTElementDefinition` object that includes `name`, `registry`, `styles`, and `template`. Registration happens by calling `Element.define(definition)` in each `define.ts`, and benchmarks import the component's `define.js` side-effect module instead of composing the definition themselves. The generated API report and `tensile.config.js` are updated to match. Behavior is functionally equivalent; this is an internal refactor that removes the `compose()` pattern.

feat(web-components): switch e2e test harness to @microsoft/fast-test-harness (#36105)

feat(web-components): implement BaseCounterBadge class and update CounterBadge component structure (#36209) ## Previous Behavior Counter badge behavior was implemented directly on `CounterBadge` and templating depended on `badgeTemplate` with `setCount()` as default content. Display logic could produce undesirable values in edge cases (for example when `overflow-count` was removed or invalid). Tests primarily used substring assertions (`toContainText`), which could allow false positives. ## New Behavior `CounterBadge` has been split so count/display behavior now lives in a reusable `BaseCounterBadge`, while visual/style attributes remain on `CounterBadge`. The counter badge template is now explicit and self-contained (`startSlotTemplate`, `<span>${x => x.displayValue}</span>`, `endSlotTemplate`) and no longer composes through `badgeTemplate`. `displayValue` is a volatile getter that safely handles zero/hidden/dot states and only applies overflow formatting when `overflowCount > 0`, preventing invalid outputs like `null+`. Test coverage was expanded with targeted regression tests for removed `overflow-count`, zero overflow count, and negative overflow count, and assertions were tightened to `toHaveText` for exact text validation.

docs(web-components): Update v2 to v3 migration doc (#36372) ## Previous Behavior The V2 → V3 migration guide (`packages/web-components/src/_docs/developer/migration.mdx`) was a high-level, snapshot-style document. It listed what was new in v3 as bullet points and relied heavily on large comparison tables, but gave little concrete guidance on how to actually update code — installation, component registration, theming, and per-component markup changes were sparse or missing. ## New Behavior The migration guide is rewritten to be a practical, task-oriented reference for moving from v2 (`2.6.1`) to v3: - Reframes the intro around v3 being a ground-up rewrite and calls out the concrete breaking areas: imports, component registration, theming, and form-control markup. - Adds a **Major Changes** overview (FAST Element v3 foundation, individual component exports, new registration model, token-based theming, `ElementInternals`, smaller bundle). - Adds a real **Bundle Size Comparison** table (v2.6.1 vs v3.0.0, with minified/gzip/brotli sizes and percentage reductions). - Adds **Usage** guidance covering installation, the `@microsoft/fast-element` peer dependency, side-effect `define` imports for individual components, `web-components.js`, and importing a component's class/template/styles/definition. - Documents the new **Theming** model, replacing design tokens and `DesignSystemProvider` with `setTheme()` (page-level and element-level, plus unsetting). - Updates the Storybook `Meta` title from "V2 → V3 Migration Guide" to "V2 to V3 Migration Guide" and the page heading to "Migration Guide".

docs(web-components): add component sticker sheet page to storybook (#36367) Adds a new Sticker Sheet page to the Web Components storybook site. The new page is located under Concepts -> Developer -> Sticker Sheet, and includes all Fluent Web Components.

docs(web-components): fix sticker sheet quirks (#36373) ## Previous Behavior * The indeterminate `<fluent-checkbox>` example wasn't wired up correctly. * The `<fluent-accordion>` example felt a bit separated. ## New Behavior * The `indeterminate` flag is set when the page is loaded. * The accordion example uses single expand mode.

fix(web-components): build package before running e2e tests (#36257) ## Previous Behavior The `e2e` script in `@fluentui/web-components` was a Node wrapper (`scripts/e2e.js`) that ran `generate-tokens` and then invoked `playwright test`. It did not build the package, and the Nx `e2e` target had no `dependsOn` entry, so `nx run web-components:e2e` ran against whatever was already in `dist/` from a prior build, or failed on a clean checkout. Token generation also ran in two places: `scripts/compile.js` runs `generate-tokens` during `build`, and `scripts/e2e.js` ran it again at test time. ## New Behavior The Nx `e2e` target declares `dependsOn: ["build"]`, so Playwright runs against a freshly built package and tokens are generated once during the build. The `e2e` and `e2e:local` npm scripts call `playwright test` directly, and `scripts/e2e.js` is removed.

fix: clean up fast-element dependency hierarchy and update to 2.10.4 (#36184) ## Previous Behavior The `@microsoft/fast-element` dependency was pinned to version `2.0.0` across multiple packages, and the dependency hierarchy had several issues: - `packages/web-components/package.json` listed `@microsoft/fast-element` and `@microsoft/focusgroup-polyfill` as `devDependencies` despite already declaring them as `peerDependencies`, duplicating the hoisted entries unnecessarily. - `packages/charts/chart-web-components/package.json` had a redundant `devDependencies` entry for `@microsoft/fast-element` pinned to `2.0.0`, and its `peerDependencies` range included the pre-release syntax `^2.0.0-beta.26 || ^2.0.0`. - `apps/vr-tests-web-components/package.json` pinned `@microsoft/fast-element` to exactly `2.0.0`. - The root `package.json` did not hoist `@microsoft/fast-element`, so the resolved version in `yarn.lock` was stuck at `2.0.0`. ## New Behavior - Removed the redundant `devDependencies` entries for `@microsoft/fast-element` and `@microsoft/focusgroup-polyfill` from `packages/web-components/package.json` since they are already declared as `peerDependencies` and satisfied by the root. - Removed the redundant `devDependencies` entry for `@microsoft/fast-element` from `packages/charts/chart-web-components/package.json`. - Simplified the `peerDependencies` range in `chart-web-components` to `^2.0.0` (dropping the unnecessary beta range). - Changed `apps/vr-tests-web-components` to use `^2.0.0` instead of the exact pin. - Added `@microsoft/fast-element` at version `2.10.4` to the root `devDependencies` so it is hoisted and all workspace packages resolve to the same up-to-date version. - `yarn.lock` now resolves `@microsoft/fast-element` to `2.10.4`.