{"owner":"microsoft","repo":"fast","hasSkills":true,"totalSkillsCount":41,"totalTokensCount":90539,"categories":["copilot-instructions","anthropic-skill","plugin-manifest","cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":[".github/copilot-instructions.md",".github/skills/documentation/SKILL.md",".github/skills/fast-bug-report/SKILL.md",".github/skills/fast-feature-request/SKILL.md",".github/skills/fast-pull-request/SKILL.md",".github/skills/rust/SKILL.md",".github/skills/shipping/SKILL.md",".github/skills/testing/SKILL.md",".github/skills/typescript/SKILL.md","packages/README.md","packages/fast-build/README.md","packages/fast-build/docs/migration/plugin-integrations.md","packages/fast-element/README.md","packages/fast-element/docs/ACKNOWLEDGEMENTS.md","packages/fast-element/docs/api-report.api.md","packages/fast-element/docs/architecture/fastelement.md","packages/fast-element/docs/architecture/html-tagged-template-literal.md","packages/fast-element/docs/architecture/intro.md","packages/fast-element/docs/architecture/overview.md","packages/fast-element/docs/architecture/updates.md","packages/fast-element/docs/arrays/api-report.api.md","packages/fast-element/docs/context/api-report.api.md","packages/fast-element/docs/declarative/api-report.api.md","packages/fast-element/docs/declarative/design.md","packages/fast-element/docs/declarative/lifecycle.md","packages/fast-element/docs/declarative/rendering.md","packages/fast-element/docs/declarative/schema-observer-map.md","packages/fast-element/docs/declarative/syntax.md","packages/fast-element/docs/di/api-report.api.md","packages/fast-element/docs/migration/fast-element-2.md","packages/fast-element/docs/migration/fast-element-3.md","packages/fast-element/docs/migration/fast-html.md","packages/fast-element/docs/styles/api-report.api.md","packages/fast-element/docs/template-bindings.md","packages/fast-router/README.md","packages/fast-router/docs/api-report.api.md","packages/fast-test-harness/README.md","sites/website/src/docs/1.x/tools/component-explorer.md","sites/website/src/docs/1.x/tools/hot-module-reload.md","sites/website/src/docs/1.x/tools/vscode.md",".cursorrules (fastapi-production-architecture-cursorrules-prompt-file.mdc)"],"skills":{".github/copilot-instructions.md":"---\nname: FAST Instructions\ndescription: This file describes the general instructions for working with the FAST monorepo, including repository structure, code style, tooling, and contribution guidelines.\napplyTo: '**/*'\n---\n\n# Instructions for FAST\n\n## General\n\n- **Explicit instruction only**: Do not take any action unless explicitly instructed. Wait for clear direction before making changes, running commands, or modifying files.\n\n## Repository Overview\n\nFAST (`@microsoft/fast`) is a Microsoft open-source monorepo for building W3C-standards-compliant Web Components. The core package is `@microsoft/fast-element` — a lightweight, performant Web Component authoring library with a declarative HTML entrypoint. Additional packages provide routing plus declarative build and test tooling.\n\n## Packages\n\nEach package includes a DESIGN.md file, read that to gain a general understanding of the code for that package.\n\n| Package | Status | Purpose |\n|---|---|---|\n| `@microsoft/fast-element` | Stable (v2) | Core Web Component library, including declarative HTML via `@microsoft/fast-element/declarative.js` |\n| `@microsoft/fast-router` | Alpha | Web Component router |\n| `@microsoft/fast-build` | Prerelease | Declarative HTML server side renderer |\n| `@microsoft/fast-test-harness` | Prerelease | Testing utilities for FASTElement components |\n\n### Sites\n\n| Package | Status | Purpose |\n|---|---|---|\n| `sites/website` | Private (not published as a package) | Documentation website source |\n| `sites/benchmarks` | Private (not published as a package) | Benchmarking site |\n\n### Example projects\n\n- `examples/design-system/` — Shared semantic design tokens (`@microsoft/fast-examples-design-system`) consumed by all example apps.\n- `examples/csr/todo-app/` — A simple To-Do app demonstrating FAST usage patterns and using the shared `@microsoft/fast-examples-design-system` tokens.\n- `examples/csr/todo-mobx-app/` — A To-Do app demonstrating how to integrate MobX state with `@microsoft/fast-element` using a single `autorun` per component (no custom bridge code).\n- `examples/ssr/chat-app/` — A declarative FAST chat demo that pre-renders with `@microsoft/fast-build` and streams canned assistant replies into the transcript. Dark theme.\n- `examples/ssr/webui-todo-app/` — A To-Do app demonstrating FAST declarative HTML with `@microsoft/webui` prerendering and `@microsoft/fast-element/declarative.js` hydration. Light theme.\n\n## Skills\n\nThese contain domain-specific guidance. Read when performing related tasks:\n\n- [TypeScript](./skills/typescript/SKILL.md) — compiler constraints, import/export conventions, decorator usage, testing patterns.\n- [Rust](./skills/rust/SKILL.md) — general guidance on performing updates between the crate and package.\n- [Shipping](./skills/shipping/SKILL.md) — pull request format, change file generation, documentation updates.\n- [Pull Request](./skills/fast-pull-request/SKILL.md) — generate a pull request description from the branch diff.\n- [Bug Report](./skills/fast-bug-report/SKILL.md) — generate a bug report issue from conversation context.\n- [Feature Request](./skills/fast-feature-request/SKILL.md) — generate a feature request issue from conversation context.\n- [Testing](./skills/testing/SKILL.md) — running tests locally and in CI, writing Playwright fixture tests.\n- [Documentation](./skills/documentation/SKILL.md) — adding documentation in code, markdown files in each package/crate, and the website.\n\n## Commands\n\nRun all commands from the monorepo root. Use workspace flags to target a single package.\n\n| Task | Command |\n|---|---|\n| Install | `npm ci` |\n| Build all | `npm run build` |\n| Build one package | `npm run build -w @microsoft/fast-element` |\n| Test all | `npm run test` |\n| Test one package | `npm run test -w @microsoft/fast-element` |\n| Test Chromium only | `npm run test:chromium` |\n| Build/test changed only | `lage build --since origin/main` |\n| Test changed only | `lage test:node test:chromium --since origin/main` |\n| Lint | `npm run lint` |\n| Lint fix | `npm run lint:fix` |\n| Format check | `npm run format:check` |\n| Format fix | `npm run format` |\n| Check (lint + format + imports) | `npm run biome:check` |\n| Check fix | `npm run biome:fix` |\n| CI check (read-only) | `npm run biome:ci` |\n| Generate change file | `npm run change` |\n| Check change files | `npm run checkchange` |\n| API docs | `npm run doc -w @microsoft/fast-element` |\n\nBuild and test commands use [Lage](https://microsoft.github.io/lage/) for dependency-aware task execution. Lage respects the package dependency graph and can run incrementally with `--since ` to only build/test changed packages and their dependents. The CI pipelines use `--since` for pull requests to skip unchanged packages.\n\nAll `lint`, `biome:check`, `biome:fix`, and `biome:ci` commands use `biome-changed`, which runs biome only on files with uncommitted git changes. The `format:check` and `format` commands use biome's own `--changed` flag to compare against the default branch.\n\n## Project Structure\n\n```\npackages//\n src/ # Source code\n index.ts # Main barrel (re-exports)\n / # Feature directories\n .ts # Implementation\n .pw.spec.ts # Co-located Playwright test\n test/ # Test harness (Vite dev server, fixtures)\n dist/ # Build output (ESM + declarations)\n docs/ # API reports (api-extractor)\n DESIGN.md # Code documentation for the package or crate\n README.md # README for published package use\n```\n\n- Source files use **kebab-case**: `element-controller.ts`, `update-queue.ts`.\n- Playwright test files use `*.pw.spec.ts` suffix, co-located next to the source they test.\n- Node test files use `*.spec.ts` suffix.\n\n## Code Style\n\n### Formatting & Linting (Biome)\n\n- 90-character print width, 4-space indent, double quotes, trailing commas.\n- Single-arg arrow functions omit parens: `x => x + 1`.\n- Import ordering enforced via `organizeImports`.\n- No `I` prefix on interfaces.\n- `any` is permitted (`noExplicitAny: off`).\n- Config: [`biome.jsonc`](../biome.jsonc).\n\n### Naming Conventions\n\n| Element | Convention | Examples |\n|---|---|---|\n| Classes | PascalCase | `ElementController`, `FASTElementDefinition` |\n| Interfaces/Types | PascalCase, no `I` prefix | `Accessor`, `Disposable`, `Expression` |\n| Methods/functions | camelCase | `getValue()`, `handleChange()` |\n| Constants | PascalCase frozen objects or camelCase | `SourceLifetime`, `emptyArray` |\n| Private fields | `_` prefix | `_template`, `_shadowRootOptions` |\n| Files | kebab-case | `element-controller.ts`, `observer-map.ts` |\n| Change callbacks | `${prop}Changed` | `childChanged()`, `templateChanged()` |\n\n### TypeScript\n\nKey constraints (details in [TypeScript skill](./skills/typescript/SKILL.md)):\n\n- ESM only (`\"type\": \"module\"`) — imports use `.js` extensions.\n- `import type { ... }` required for type-only imports (`verbatimModuleSyntax`).\n- Named exports only — no default exports.\n- Legacy decorators enabled (`experimentalDecorators: true`).\n- `strictNullChecks` and `noImplicitAny` enabled.\n\n## Tooling\n\n| Tool | Purpose |\n|---|---|\n| npm workspaces | Package management |\n| Lage | Task runner — dependency-aware builds and incremental testing |\n| TypeScript | Compilation |\n| Rollup | Bundling (`fast-element` only) |\n| Playwright | Testing |\n| Vite | Test dev server |\n| api-extractor | API documentation + `.d.ts` rollup |\n| beachball | Change files, versioning, publishing |\n| Biome | Formatting + Linting |\n| lefthook | Pre-commit hooks (runs `biome:check` and `checkchange` on staged files) |\n| Rust | Rendering Declarative templates (`fast-build` package and `microsoft-fast-build` crate only) |\n\n## Acceptance Checklist\n\nBefore finishing any change, run these commands from the monorepo root and confirm they pass:\n\n- [ ] `npm run build` — all packages build successfully\n- [ ] `npm run test` — all tests pass\n- [ ] `npm run biome:check` — Biome linting and formatting pass\n- [ ] `npm run checkchange` — beachball change files exist for any `packages/*` changes\n\nRead the [shipping skill](./skills/shipping/SKILL.md) and ensure you have updated everything outlined in that file.\n",".github/skills/documentation/SKILL.md":"---\nname: documentation\ndescription: Add documentation for contributors and developers.\n---\n\nDocumentation exists in 3 forms, code comments, design/architectural documentation that is made up of markdown files describing code flow and core concepts (such as DESIGN.md), and the documentation website.\n\nDesign/architectural documentation such as DESIGN.md should always be kept up-to-date.\n\nThe website captures the documentation primarily for the `@microsoft/fast-element` package. Other packages are treated as tangential, so testing packages or other utilities should have their own sections.\n\nThe website has been written in 11ty and primarily consists of markdown files. When making changes, ensure that the website has been scanned on whichever latest major version is available. These are organized by folder, so if 1.x/2.x/3.x folders are available, you will update the documentation in the 3.x folder.\n\nIf you are making a breaking change, ensure the migration document has been updated.\n\nAll markdown documentation aside from the package/crate level DESIGN.md files are in that package/crates docs folder.\n\nAny documentation created for the website should be written with the developer implementing the package in mind, it is not intended for other audiences.\n",".github/skills/fast-bug-report/SKILL.md":"---\nname: fast-bug-report\ndescription: Generate a bug report issue for the FAST repository using the provided template.\n---\nThis prompt only applies to generating Bug Report issues for the FAST repository.\n\nDo not create or modify any existing Github issues. This skill is only for\ngenerating the markdown content for a new issue based on the provided template.\n\nBased on the conversation context, generate a bug report as a markdown code\nblock using the template located at\n[../../ISSUE_TEMPLATE/bug-report.md](../../ISSUE_TEMPLATE/bug-report.md).\n\nThe summary should clearly state what the bug is and which part of the system\nis affected.\n\nRepro or Code Sample should provide clear, minimal steps to reproduce the issue.\nInclude a code snippet, repository link, or gist if possible.\n\nExpected Behavior should describe what the correct behavior should be.\n\nCurrent Behavior should explain what actually happens instead. Include the full\nerror message and stack trace if applicable. Mention screenshots if they would\nhelp illustrate the problem.\n\nPossible Solution is optional. Include it only if there is a concrete idea about\nthe cause or fix. Mention if the reporter is willing to contribute a fix.\n\nContext should explain how the bug affects the user and what they are trying to\naccomplish. This helps prioritize and design the right solution.\n\nYour Environment should capture relevant details: OS, device, browser, and\npackage version.\n\nSearch for existing open or closed issues that overlap with this bug report.\nIf duplicates or related issues exist, mention them in the Context section.\n\nSuggest a concise issue title in the format `fix: [what is the issue?] in [where is the issue?]`.\n\nProvide the markdown code block only, without any additional commentary or explanation.\n\nAny comments in the template can be removed since they're only meant to provide\nguidance on how to fill out the template, and are not intended to be part of the\nfinal issue body.\n",".github/skills/fast-feature-request/SKILL.md":"---\nname: fast-feature-request\ndescription: Generate a feature request issue for the FAST repository using the provided template.\n---\nThis prompt only applies to generating Feature Request issues for the FAST repository.\n\nDo not create or modify any existing Github issues. This skill is only for\ngenerating the markdown content for a new issue based on the provided template.\n\nBased on the conversation context, generate a feature request as a markdown code\nblock using the template located at\n[../../ISSUE_TEMPLATE/feature-request.md](../../ISSUE_TEMPLATE/feature-request.md).\n\nThe summary should clearly state what the feature is and why it matters, focusing\non user value rather than implementation details.\n\nExpected Behavior should describe how the feature would work from an end-user or\ndeveloper perspective. Be specific about the desired outcome.\n\nCurrent Behavior should explain the gap — what exists today and how the absence of\nthis feature affects users. If there is a workaround, mention it briefly.\n\nPossible Solution is optional. Include it only if there is a concrete implementation\nidea worth capturing. Prefer high-level direction over prescriptive code.\n\nContext should explain the motivation — what the user is trying to accomplish\nand why this feature would help. Mention alternatives that were considered, if any.\n\nExamples is optional. Include it when code snippets, screenshots, or usage\nscenarios would clarify the request.\n\nSearch for existing open or closed issues that overlap with this feature request.\nIf duplicates or related issues exist, mention them in the Context section.\n\nSuggest a concise issue title in the format `feat: add [what] to/in [where]`.\n\nProvide the markdown code block only, without any additional commentary or explanation.\n\nAny comments in the template can be removed since they're only meant to provide\nguidance on how to fill out the template, and are not intended to be part of the\nfinal issue body.\n",".github/skills/fast-pull-request/SKILL.md":"---\nname: fast-pull-request\ndescription: Generate a pull request description for the FAST repository using the provided template.\n---\nThis skill only applies to generating Pull Request descriptions for the FAST repository.\n\nDo not create or modify any existing Github pull requests. This skill is only for\ngenerating the markdown content for a pull request description based on the provided template.\n\nBased on the conversation context, generate a pull request description as a markdown code\nblock using the template located at\n[../../pull_request_template.md](../../pull_request_template.md).\n\nUse the Pull Request Template to generate a markdown code block for the most\nrelevant work on this git branch, compared to `main`.\n\nThe Description should be either a summary description of the content of the branch,\nor a list of the most relevant changes made in the branch. The goal is to address\nthe purpose of the pull request in a concise manner, rather than detailing every change. \"Why\"\nand \"what\" over \"how\".\n\nDetermine if any current github issues are being addressed by this work, and\nlist them in the Issues section with links. If none are found, remove the Issues section.\n\nThe reviewer notes section is optional. Include it only if there are specific\nareas where you would like feedback or attention from the reviewer.\n\nThe Test Plan section should outline any issues that need to be verified before merging,\nor steps to reproduce the behavior locally. Even a brief note is helpful, such as \"All existing tests pass\".\n\nThe checklist section should be completed to indicate the status of various\naspects of the pull request.\n\nIf there are change files that have been added to the PR, check the box labeled \"I have included a change request file using `$ npm run change`\".\n\nIf any new tests have been added, check the box labeled \"I have added tests for my changes.\"\n\nCheck the terminal output for evidence of passing tests, and check the box labeled \"I have tested my changes.\" if tests have been run and are passing. If not, leave the box unchecked.\n\nIf any doc blocks have been added or modified, or if any documentation files have been added or modified, check the box labeled \"I have updated the project documentation to reflect my changes.\" This also applies to any changes made to api-report files.\n\nThe final checkbox must be checked by the pull request author. It should never be checked when generating this PR description.\n\nThe Next Steps section is optional. Include it only if there are specific follow-up tasks\nor work items that should be addressed after merging this PR, such as updating documentation, adding new tests, or performing code cleanup. If any existing issues are being addressed by the next steps, reference them here.\n\nProvide the markdown code block only, without any additional commentary or explanation.\n\nAny comments in the template can be removed since they're only meant to provide\nguidance on how to fill out the template, and are not intended to be part of the\nfinal PR description.\n",".github/skills/rust/SKILL.md":"---\ndescription: Use this guide when working on Rust changes in the FAST monorepo.\nname: rust\n---\n\n# Working with the Rust crate and the Rust NodeJS CLI\n\nThe primary location for the Rust logic should exist within a crate. If the logic is made accessible in the NodeJS environment via wrapping the crate and using a wasm bindgen, as much as possible any logic that exists in Rust should not be duplicated in JavaScript/TypeScript.\n\n## Breaking changes\n\nUnderstand [semver](https://semver.org/) and check the crate and package version. If the version is currently in a prerelease state, update the APIs with breaking changes as necessary and ensure that any generated pull request descriptions capture this.\n",".github/skills/shipping/SKILL.md":"---\ndescription: Use this skill when contributing changes to the FAST monorepo — creating pull requests, generating change files, writing PR descriptions, and keeping documentation up to date.\nname: shipping\n---\n\n# Shipping Patterns for FAST\n\nUse this guide when shipping changes in the FAST monorepo — writing PR descriptions, generating change files, and keeping documentation up to date.\n\n# Guardrails\n\nDo NOT perform any of the following actions autonomously. These require explicit human action:\n\n- **Do not merge or close pull requests** — no `gh pr merge`, `gh pr close`, or equivalent.\n- **Do not publish packages** — no `npm publish`, `beachball publish`, or release operations.\n- **Do not modify branch protection or repository settings**.\n\n## Key references\n\nRead these documents for additional context when needed:\n\n- [`.github/pull_request_template.md`](../../pull_request_template.md) — PR description template (source of truth for PR structure).\n- [`CONTRIBUTING.md`](../../../CONTRIBUTING.md) — Full contributor guide (machine setup, branching, governance).\n- [`BRANCH_GUIDE.md`](../../../BRANCH_GUIDE.md) — Branch management conventions.\n- [`beachball.config.js`](../../../beachball.config.js) — Beachball configuration (ignored patterns, publish settings).\n- [`CODE_OF_CONDUCT.md`](../../../CODE_OF_CONDUCT.md) — Community standards.\n\n### Package/Crate references\n\nRead these documents, they are located at the root of the specific package or crate, e.g. `packages//.md` and relate to the package/crates they are located in. When making changes in the package/crate afterwards update these files if necessary.\n\n- `DESIGN.md` - Explains the code patterns.\n- `README.md` - Explains how a developer/agent would use this package/crate.\n\n# Commit and PR title conventions\n\nUse [conventional commit](https://www.conventionalcommits.org/) format for PR titles and merge commit messages:\n\n```\n: \n```\n\nCommon types: `feat`, `fix`, `chore`, `docs`, `refactor`, `test`, `perf`.\n\nExamples:\n- `feat: add shadow DOM support to declarative templates`\n- `fix: resolve memory leak in template binding`\n- `chore: update dev dependencies`\n\n# Pull requests\n\nUse the repository's PR template at [`.github/pull_request_template.md`](../../pull_request_template.md) as the basis for all pull request descriptions.\n\nProvide the markdown code block only, without any additional commentary or explanation.\n\nThe comments in the template can be removed since they're only meant to provide guidance on how to fill out the template, and are not intended to be part of the final PR description.\n\nFill out each section as detailed below.\n\n## Description\n\nThe Description should be either a summary description of the content of the branch,\nor a list of the most relevant changes made in the branch. The goal is to address\nthe purpose of the pull request in a concise manner, rather than detailing every change. \"Why\"\nand \"what\" over \"how\".\n\n## Issues\n\nDetermine if any current github issues are being addressed by this work, and\nlist them in the Issues section with links. If none are found, remove the Issues section.\n\n## Reviewer Notes\n\nThe reviewer notes section is optional. Include it only if there are specific\nareas where you would like feedback or attention from the reviewer.\n\n## Test Plan\n\nThe Test Plan section should outline any issues that need to be verified before merging,\nor steps to reproduce the behavior locally. Even a brief note is helpful, such as \"All existing tests pass\".\n\n## Checklist\n\nThe checklist section should be completed to indicate the status of various\naspects of the pull request.\n\nIf there are change files that have been added to the PR, check the box labeled \"I have included a change request file using `$ npm run change`\".\n\nIf any new tests have been added, check the box labeled \"I have added tests for my changes.\"\n\nCheck the terminal output for evidence of passing tests, and check the box labeled \"I have tested my changes.\" if tests have been run and are passing. If not, leave the box unchecked.\n\nIf any doc blocks have been added or modified, or if any documentation files have been added or modified, check the box labeled \"I have updated the project documentation to reflect my changes.\" This also applies to any changes made to api-report files.\n\nThe final checkbox must be checked by the pull request author. It should never be checked when generating this PR description.\n\n## Next Steps\n\nThe Next Steps section is optional. Include it only if there are specific follow-up tasks\nor work items that should be addressed after merging this PR, such as updating documentation, adding new tests, or performing code cleanup. If any existing issues are being addressed by the next steps, reference them here.\n\n# Acceptance checklist\n\nBefore making a change, if the change is addressing a bug make sure you write a test first and ensure that it is failing:\n\n```bash\nnpm run build # all packages build successfully\nnpm run test # test fails\n```\n\nBefore finishing any change, run these commands from the monorepo root and confirm they pass:\n\n```bash\nnpm run build # all packages build successfully\nnpm run test # all tests pass\nnpm run format:check # Prettier formatting is correct\nnpm run checkchange # Beachball change files exist for packages/* changes\n```\n\n# Change files\n\nAfter completing a change to any package under `packages/`, generate a Beachball change file:\n\n```bash\n# This should be run from the monorepo root\nnpm run change\n```\n\nThis walks through the steps to create a change description file that is required for versioning and publishing. The CI gate `npm run checkchange` will fail if a change file is missing for a modified package.\n\n## Change comments\n\nWrite the `comment` field as release-note text, not as a commit message. Use a\nconcise sentence that starts with a capital letter and ends with a period. Do not\nprefix comments with conventional commit types such as `fix:`, `feat:`, or\n`chore:`.\n\nBeachball uses change-file comments to generate package changelogs and release\nnotes. Sentence-style comments read cleanly in those user-facing outputs, while\ncommit-style prefixes duplicate the separate change type metadata and add noise.\n\n## Change types\n\nWhen prompted, select the appropriate change type:\n\n| Type | When to use |\n|---|---|\n| `major` | Breaking changes to public API |\n| `minor` | New features, non-breaking additions |\n| `patch` | Bug fixes, minor corrections |\n| `none` | Changes that don't affect the published package (tests, docs, tooling) |\n\n## When change files are NOT required\n\nThe Beachball config ([`beachball.config.js`](../../../beachball.config.js)) ignores these paths — changes limited to them do not need change files:\n\n- `.github/` — CI configs, templates, skills\n- Test files (`src/e2e/`, `src/tests/`, `src/fixtures/`)\n- `package-lock.json`\n- `.vscode/`, `.prettierrc`\n\nAdditionally, [`build/scripts/checkchange.mjs`](../../../build/scripts/checkchange.mjs) (which wraps `beachball check` for the `checkchange` npm script) skips the check entirely on **manual version bump** branches authored by a repo admin. Specifically, both of the following must be true for the current run:\n\n1. Branch name matches `^publish_\\d+$` (beachball's documented publish-branch convention).\n2. The actor (`$GITHUB_ACTOR` in CI; locally, the user from `gh api user`) has the `admin` role on `microsoft/fast`, verified via the GitHub REST API.\n\nIf either condition fails, the change-file requirement applies as before. See [`CONTRIBUTING.md` > Manual version bumps](../../../CONTRIBUTING.md#manual-version-bumps) for the full rationale and reviewer expectations.\n\n## Cross-branch targeting\n\nWhen working across feature branches, target the branch explicitly:\n\n```bash\nnpm run change -- --branch origin/{branch-name}\n```\n\n## Multiple unrelated changes\n\nIf addressing multiple unrelated issues, prefer separate pull requests.\n\n# Breaking changes\n\nWhen introducing breaking changes:\n\n1. Select `major` as the change type when running `npm run change`.\n2. Document the migration strategy in `packages//docs/migration/.md`.\n\nFormat for a migration document:\n\n```md\n# Migrating from previous versions\n\n## v1 to v2\n\n- Export `Foo` has been renamed to `Bar`.\n- `Bat` has been updated to use the new API [`BatConfig`](link/to/api).\n```\n\nIf the breaking change is significant or requires multiple PRs, open a [discussion](https://github.com/microsoft/fast/discussions) first.\n\n# Documentation\n\nAfter any changes ensure that the documentation is up to date, this includes the files DESIGN.md and README.md files for any packages/crates that have been modified. If your changes update or add to the public API, update the sites/website/src/docs/ files. Only update the latest version, these are denoted by major versions in their folder names inside the docs folder, 1.x, 2.x, etc., find the latest version of the docs and modify them if necessary.\n\nWhen adding or modifying exported APIs, run the website prebuild script to regenerate API documentation from the api-extractor output:\n\n```bash\nnpm run prebuild -w sites/website\n```\n\nThis runs [`sites/website/scripts/generate-docs.cjs`](../../../sites/website/scripts/generate-docs.cjs), which copies API documentation from each package's extracted API reports into the website source. Run this after building packages to ensure generated documentation stays in sync with the codebase.\n",".github/skills/testing/SKILL.md":"---\nname: testing\ndescription: Use this skill when running or writing tests in the FAST monorepo — local test execution, CI workflows, Playwright fixtures, and WebUI integration testing.\n---\n\n# Testing Patterns for FAST\n\nUse this guide when running or writing tests in the FAST monorepo. FAST uses [Playwright](https://playwright.dev/) for integration testing with a [Vite](https://vitejs.dev/) dev server.\n\n## Running tests\n\n### Locally\n\n#### First-time setup\n\nAfter cloning and installing dependencies (`npm ci`), install Playwright browsers:\n\n```bash\nnpx playwright install --with-deps\n```\n\n#### Commands\n\nAll commands are run from the **monorepo root**. Use `-w` to target a specific package.\n\n| Task | Command |\n|---|---|\n| Run all tests (all browsers) | `npm run test` |\n| Run all tests (Chromium only) | `npm run test:chromium` |\n| Test a single package (all browsers) | `npm run test -w @microsoft/fast-element` |\n| Test a single package (Chromium only) | `npm run test:chromium -w @microsoft/fast-element` |\n| Test changed packages only | `npx lage test:node test:chromium --since origin/main` |\n\n#### Interactive / debug workflows\n\nFor FAST declarative tests in `@microsoft/fast-element`, these additional scripts are available:\n\n| Task | Command |\n|---|---|\n| Playwright UI mode | `npm run test:ui:declarative -w @microsoft/fast-element` |\n| Start declarative source server | `npm run test-server:declarative -w @microsoft/fast-element` |\n| Rebuild fixtures | `npm run build:fixtures -w @microsoft/fast-element` |\n| Build fixtures with webui | `npm run build:fixtures:webui -w @microsoft/fast-element` |\n| Run webui integration tests | `npm run test:webui-integration -w @microsoft/fast-element` |\n\n**Playwright UI mode** (`test:ui`) starts a visual test runner where you can select and debug individual tests, view traces, and inspect DOM snapshots.\n\n**Declarative browser workflows** resolve `@microsoft/fast-element` package imports directly to `src` and let Vite transpile TypeScript on demand. Vite does not type-check these modules; the package build remains responsible for type checking, while `test:exports` imports every emitted package export.\n\n### Through GitHub Actions\n\nThe repository uses several CI workflows to validate changes.\n\n#### PR validation (ci-validate-pr.yml)\n\nRuns on every pull request targeting `main`, `releases/*`, or `features/*` branches. Tests run on **Ubuntu with Chromium only** for fast feedback.\n\nKey steps:\n- Checks for change files (`npm run checkchange`)\n- Biome lint/format check\n- Builds affected packages (incremental with `--since`)\n- Runs `test:node` and `test:chromium` for affected packages\n\n#### Cross-platform validation (ci-validate-platforms.yml)\n\nRuns on pushes to `main`, PRs targeting `main`, and on a weekly schedule. Tests run on **Ubuntu, Windows, and macOS** with **Chromium, Firefox, and Safari**.\n\nThis ensures cross-platform and cross-browser compatibility.\n\n#### WebUI integration testing (ci-webui-integration.yml)\n\nA dedicated workflow for validating FAST's integration with `@microsoft/webui`. This workflow runs on:\n\n- **Manual dispatch** (`workflow_dispatch`)\n- **Pushes to `webui/*` branches**\n\n> **Note:** This workflow does _not_ run on regular pull requests. It is scoped to `webui/*` branches to test integration changes in isolation before they land on `main`.\n\nThe workflow builds all packages, installs Playwright Chromium, and runs:\n\n```bash\nnpm run test:webui-integration -w @microsoft/fast-element\n```\n\nThis builds each fixture with `webui build --plugin=fast`, renders the protocol with the fixture's `state.json`, and runs the same Playwright specs against the webui-rendered output.\n\nTo trigger WebUI integration tests for your changes:\n\n1. Create a branch with the `webui/` prefix (e.g., `webui/my-integration-change`).\n2. Push the branch — the workflow runs automatically.\n3. Alternatively, trigger the workflow manually from the Actions tab using `workflow_dispatch`.\n\n#### Azure Pipelines (azure-pipelines-ci.yml)\n\nThe repository also has an Azure DevOps pipeline that runs on PRs to `main`. This pipeline runs in a 1ES-managed environment and includes SDL compliance checks in addition to building and testing.\n\n## Writing tests\n\nFAST tests are [Playwright](https://playwright.dev/) integration tests that run against fixture pages served by Vite.\n\n### Test file conventions\n\n- Test files use the `*.spec.ts` suffix (specifically `*.pw.spec.ts` for package `src/` tests).\n- Tests for developer-authored declarative markup and directives live in the matching\n `test/declarative/fixtures///.spec.ts` fixture.\n- Tests for implementation APIs and lifecycle behavior are co-located with their source as\n `src//.pw.spec.ts`.\n\n### Writing declarative fixture tests\n\nFixture tests in `@microsoft/fast-element/test/declarative/fixtures` are the primary way to verify declarative template features. Each fixture is a self-contained test case with its own HTML, state, templates, and component definitions.\n\nWhen changing declarative syntax, directive parsing, template generation, hydration behavior, or other user-authored template behavior, add or update a declarative fixture and exercise it in browser. Source-level parser tests may supplement narrow parsing edge cases, but they should not be the only coverage for syntax that users write in `entry.html` or `templates.html`. Use the local README files under `packages/fast-element/test/declarative/fixtures/` and each fixture category to choose the right fixture type and follow category-specific examples.\n\nFor a complete guide on creating fixtures — including how to write `entry.html`, `state.json`, `templates.html`, `main.ts`, and spec files — see:\n\n📄 **[Writing Fixtures](../../../packages/fast-element/test/declarative/fixtures/WRITING_FIXTURES.md)**\n\n### Quick example\n\n```typescript\nimport { expect, test } from \"@playwright/test\";\n\ntest.describe(\"my-feature\", async () => {\n test(\"renders correctly\", async ({ page }) => {\n await page.goto(\"/fixtures/bindings/my-feature/\");\n\n const element = page.locator(\"my-element\");\n await expect(element).toHaveText(\"Hello\");\n });\n});\n```\n",".github/skills/typescript/SKILL.md":"---\ndescription: Use this guide when working on TypeScript changes in the FAST monorepo — authoring Web Components, writing templates and styles, working with the observable/reactive system, and testing.\nname: typescript\n---\n\n# TypeScript Patterns for FAST\n\n## Modules\n\n`fast-element` enables `verbatimModuleSyntax`, so type-only imports must use `import type`\nor the inline `type` qualifier:\n\n```ts\nimport type { Notifier, Subscriber } from \"./notifier.js\";\nimport { type Constructable, isFunction } from \"../interfaces.js\";\n```\n\nSub-entry-points expose focused APIs through the `exports` map:\n\n```ts\nimport { twoWay } from \"@microsoft/fast-element/two-way.js\";\nimport { reactive } from \"@microsoft/fast-element/state.js\";\n```\n\nThe barrel `index.ts` explicitly lists every re-export grouped by subsystem — no\n`export *` statements.\n\nAside from the `index.ts` or `index.*.ts` files there should be no barrel exports.\n\n## Side Effects\n\nDo not add side effectful code and do not add `sideEffects` to `package.json` files.\nAPIs added should import named exports.\n\n## Browser APIs\n\n### Do not use\n\nOur stance as a framework library is that certain browser APIs are best avoided by\nthe framework. We may facilitate the use of them through our provided APIs.\n\nList of APIs to avoid implementing in FAST packages:\n- `requestIdleCallback`\n- `setTimeout`\n- `setInterval`\n\n### Avoid\n\nSome browser APIs can be used but should be avoided as a developer may encounter\nedge cases with task queuing or other logic their app is executing.\n\nList of APIs to avoid in FAST packages:\n- `requestAnimationFrame`\n- `queueMicrotask`\n\n## Custom elements\n\nElements extend `FASTElement`. Do **not** use the `@customElement` decorator.\n\nUse `define()` for registration. `define()` returns a `Promise` that resolves\nimmediately when a template is provided:\n\nExample define.ts (side-effect import):\n```ts\nexport class MyElement extends FASTElement {\n @observable items: string[] = [];\n}\n\nawait MyElement.define({\n name: \"my-element\",\n template,\n styles,\n});\n```\n\n## Templates\n\nTemplates use the `html` tagged template literal typed to the element class:\n\n```ts\nimport { html } from \"@microsoft/fast-element/html.js\";\nimport { repeat } from \"@microsoft/fast-element/repeat.js\";\nimport { when } from \"@microsoft/fast-element/when.js\";\nimport type { MyElement } from \"./my-element.js\";\n\nexport const template = html`\n

${x => x.title}

\n ${when(x => x.showList, html`\n
    \n ${repeat(\n x => x.items,\n html`
  • ${x => x}
    • `\n )}\n
\n `)}\n`;\n```\n\n### Binding syntax\n\n| Prefix | Purpose | Example |\n|---|---|---|\n| `${x => ...}` | Content or attribute | `${x => x.name}` |\n| `@event` | Event listener | `@click=${x => x.handleClick()}` |\n| `@event` | Event with context | `@click=${(x, c) => c.parent.remove(x)}` |\n| `:prop` | DOM property | `:value=${twoWay(x => x.description)}` |\n| `?attr` | Boolean attribute | `?disabled=${x => !x.isValid}` |\n\nTwo-way bindings require a sub-entry-point import:\n\n```ts\nimport { twoWay } from \"@microsoft/fast-element/two-way.js\";\n```\n\n### Partial HTML\n\nUse `html.partial()` to inject pre-built HTML strings into a template without creating\na full `ViewTemplate`:\n\n```ts\nhtml`\n
${html.partial(\"static markup\")}
\n`;\n```\n\n## Styles\n\nStyles use the `css` tagged template literal. They attach through the element definition's\n`styles` property:\n\n```ts\nimport { css } from \"@microsoft/fast-element/css.js\";\n\nexport const styles = css`\n :host {\n display: block;\n padding: 16px;\n }\n`;\n```\n\nFor declarative HTML definitions, styles live in a separate `.styles.css` file linked from\nboth the initial shadow root template and the ``:\n\n```html\n\n \n\n```\n\n`css.partial()` works the same way as `html.partial()` — injecting raw CSS strings.\n\n## Reactivity\n\n`@attr` maps HTML attributes to properties. `@observable` creates reactive properties\ntracked by templates. `@volatile` marks getters whose dependencies change between calls:\n\n```ts\nimport { FASTElement } from \"@microsoft/fast-element/fast-element.js\";\nimport { attr, nullableNumberConverter } from \"@microsoft/fast-element/attr.js\";\nimport { Observable, observable } from \"@microsoft/fast-element/observable.js\";\nimport { volatile } from \"@microsoft/fast-element/volatile.js\";\n\nclass MyElement extends FASTElement {\n @attr label?: string;\n @attr({ mode: \"boolean\" }) active?: boolean;\n @attr({ converter: nullableNumberConverter }) count?: number;\n\n @observable private _items: string[] = [];\n\n // Convention: ${propertyName}Changed\n labelChanged(prev: string | undefined, next: string | undefined) {}\n\n @volatile\n get sortedItems(): readonly string[] {\n return [...this._items].sort();\n }\n}\n```\n\nNotify the system after in-place mutations that it cannot detect automatically:\n\n```ts\nthis._items.splice(index, 1);\nObservable.notify(this, \"_items\");\n```\n\nMake plain objects observable via the state sub-entry-point:\n\n```ts\nimport { reactive } from \"@microsoft/fast-element/state.js\";\nconst todo = reactive({ description: \"Buy milk\", done: false });\n```\n\n## Testing\n\nTests use Playwright Test (`*.pw.spec.ts`) and combine two patterns within the same file.\n\n### Direct-import tests\n\nFor logic that does not need browser APIs — the test callback takes no parameters:\n\n```ts\nimport { expect, test } from \"@playwright/test\";\nimport { Observable } from \"./observable.js\";\n\ntest.describe(\"Observable\", () => {\n test(\"can get a notifier\", () => {\n const notifier = Observable.getNotifier(new Model());\n expect(notifier).toBeInstanceOf(PropertyChangeNotifier);\n });\n});\n```\n\n### Browser-evaluated tests\n\nFor tests requiring DOM APIs, navigate to the Vite dev server and import via\n`\"/main.js\"`. The `@ts-expect-error` comment is required because TypeScript cannot\nresolve the URL-based import:\n\n```ts\ntest(\"renders element\", async ({ page }) => {\n await page.goto(\"/\");\n\n const result = await page.evaluate(async () => {\n // @ts-expect-error: Client module.\n const { FASTElement, html, uniqueElementName } = await import(\"/main.js\");\n // ... test logic ...\n return someSerializableValue;\n });\n\n expect(result).toBe(expected);\n});\n```\n\nOnly serializable values can cross the `page.evaluate` boundary — run `expect()`\nassertions outside it on the returned data.\n\nThe test harness at `packages//test/main.ts` re-exports source modules for\nbrowser tests. When adding new package exports, add them there too.\n\n## TypeScript idioms\n\n### Const-type merging for enumerations\n\nFrozen const objects paired with a type extracted from their values replace TypeScript\n`enum`:\n\n```ts\nexport const SourceLifetime = {\n default: undefined,\n couple: 1,\n} as const;\n\nexport type SourceLifetime =\n (typeof SourceLifetime)[keyof typeof SourceLifetime];\n```\n\n### Interface-const merging\n\n`FASTElement` is both an interface (instance shape) and a const (constructor). Static\nmethods use `typeof` to carry overloaded signatures:\n\n```ts\nexport const FASTElement: {\n new (): FASTElement;\n define: typeof define;\n} = Object.assign(createFASTElement(HTMLElement), { define });\n```\n\n### Tagged template intersection types\n\n`html` and `css` are typed as intersections of a tagged template function and a\n`.partial()` method:\n\n```ts\ntype HTMLTemplateTag = ((\n strings: TemplateStringsArray,\n ...values: TemplateValue[]\n) => ViewTemplate) & {\n partial(html: string): InlineTemplateDirective;\n};\n```\n","packages/README.md":"# FAST Packages\n\nOur web component packages.\n\n## `@microsoft/fast-element`\n\n[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)\n[![npm version](https://badge.fury.io/js/%40microsoft%2Ffast-element.svg)](https://badge.fury.io/js/%40microsoft%2Ffast-element)\n\nThe `@microsoft/fast-element` library is a lightweight means to easily build performant, memory-efficient, standards-compliant Web Components. FAST Elements work in every major browser and can be used in combination with any front-end framework or even without a framework. To get up and running with `@microsoft/fast-element` see [the Getting Started guide](https://fast.design/docs/getting-started/quick-start).\n\n## `@microsoft/fast-router`\n\n[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)\n[![npm version](https://badge.fury.io/js/%40microsoft%2Ffast-foundation.svg)](https://badge.fury.io/js/%40microsoft%2Ffast-router)\n\nThe `@microsoft/fast-router` package contains a history-based navigation and routing solution designed around Web Components. By using `fast-router`, you can create multi-page and full application experiences. The router works with any Web Components, but has special support for Web Components built on FAST.","packages/fast-build/README.md":"# FAST Build\n\n[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)\n[![npm version](https://badge.fury.io/js/%40microsoft%2Ffast-build.svg)](https://badge.fury.io/js/%40microsoft%2Ffast-build)\n\nThe `fast-build` package renders the declarative HTML template syntax of [`@microsoft/fast-element`](https://www.npmjs.com/package/@microsoft/fast-element), primarily for use in testing environments. It is powered by a WebAssembly core with zero runtime npm dependencies.\n\n> **Note:** For production server-side rendering, we recommend using the [`@microsoft/webui`](https://github.com/microsoft/webui) project instead.\n\n## Installation\n\n### From NPM\n\nTo install the latest `@microsoft/fast-build` package using `npm`:\n\n```shell\nnpm install --save @microsoft/fast-build\n```\n\nWithin your JavaScript or TypeScript code, you can then import library APIs like this:\n\n```ts\nimport { render } from '@microsoft/fast-build';\n```\n\n## CLI usage\n\nOnce installed, the `fast` binary is available. Use the `build` subcommand to render an HTML template with an optional JSON state file, or `convert` to convert a FAST declarative HTML template to another supported syntax:\n\n```shell\nfast build [options]\nfast convert [options]\n```\n\n### Build options\n\n| Option | Default | Description |\n|---|---|---|\n| `--entry=\"\"` | `index.html` | Entry HTML template to render |\n| `--state=\"\"` | `{}` when omitted | JSON file containing the template state. If omitted, no state file is loaded and rendering uses an empty state object. If `--state` is provided, the file must exist. |\n| `--output=\"\"` | `output.html` | Where to write the rendered HTML |\n| `--templates=\"\"` | _(none)_ | Glob pattern(s) for custom element template HTML files. Separate multiple patterns with commas. A warning is printed if not provided in non-streaming mode or if no files match a pattern. |\n| `--attribute-name-strategy=\"\"` | `camelCase` | Strategy for mapping HTML attribute names to state property names on custom elements. `\"camelCase\"` converts dashes to camelCase (e.g. `foo-bar` → `fooBar`). `\"none\"` preserves dashes (e.g. `foo-bar` → `foo-bar`). See [Attribute name strategy](#attribute-name-strategy). |\n| `--markers_v2[=true/false]` | `false` | Emit FAST Element 2.x indexed hydration markers instead of the default FAST Element 3.x data-free markers. |\n| `--config=\"\"` | `fast-build.config.json` | Path to a JSON configuration file. If omitted, `fast-build.config.json` in the current directory is used when present. CLI arguments take precedence over config values. See [Configuration file](#configuration-file). |\n| `--stream[=true/false]` | `false` | Write rendered HTML chunks directly to stdout instead of writing `--output`. Valueless `--stream` is treated as `true`. |\n\n### Example\n\nGiven an `index.html`:\n\n```html\n\n \n

{{title}}

\n

{{description}}

\n \n\n```\n\nAnd a `state.json`:\n\n```json\n{\n \"title\": \"Hello FAST\",\n \"description\": \"Server-side rendered with WebAssembly.\"\n}\n```\n\nRun:\n\n```shell\nfast build --entry=index.html --state=state.json --output=output.html\n```\n\nProduces `output.html`:\n\n```html\n\n \n

Hello FAST

\n

Server-side rendered with WebAssembly.

\n \n\n```\n\n### Streaming output\n\nPass `--stream`, `--stream=true`, or `--stream=false`, or set\n`\"stream\": true` in `fast-build.config.json`, to control stdout streaming. When\nstreaming is enabled, the CLI writes raw rendered HTML chunks to stdout, does\nnot write the `--output` file, and does not print the normal `Built: ...`\nmessage.\n\n```shell\nfast build --entry=index.html --state=state.json --stream\n```\n\nStreaming is simulated by the WebAssembly renderer: chunks are prepared in\nmemory, returned to JavaScript as a JSON array, parsed by the CLI, and then\nwritten to stdout. `--stream` uses the same entry renderer with its stream flag\nenabled and passes an empty templates map when no `--templates` glob is\nprovided. Chunk boundaries are safe for HTML parsing:\n\n- Attribute bindings stay within complete opening tag chunks.\n- Custom element opening chunks include the complete Declarative Shadow DOM\n template.\n- Streamed output uses the same renderer preprocessing and custom-element host\n attribute propagation as normal output.\n- Empty chunks are omitted.\n- Concatenating all chunks matches the normal non-streamed render.\n\n### Performance benchmarks for contributors\n\nThe renderer discovers tags and bindings in a forward scan, eliminating repeated\nremaining-suffix searches for adjacent custom elements and plain tags. Existing\nWASM exports, rendered bytes, default markers, and `markers_v2` remain compatible.\nRendering is still synchronous, and `--stream` still buffers all chunks in WASM.\n\nFrom a FAST repository checkout, not an installed npm package:\n\n```shell\nnpm run build -w @microsoft/fast-build\nnpm run bench:render -w @microsoft/fast-build -- --case=url_sink_siblings --output=/tmp/fast-render.json\nnpm run bench:render -w @microsoft/fast-build -- --case=url_sink_siblings --check-scaling\n```\n\nThe runner benchmarks the actual packaged WASM in fresh child processes in both\nmarker modes, recording timing, CPU, output hashes, throughput, and peak RSS.\nUse `--case`, `--counts`, `--samples`, or `--compare=` to narrow\nor compare a run. Output files are never overwritten. Normal tests verify the\nsame fixtures against pre-optimization hashes without flaky timing thresholds.\nSee the [benchmark guide](../../crates/microsoft-fast-build/benchmark-baselines/README.md)\nfor native Criterion benchmarks, fixture sizes, methodology, and limitations.\n\nThe guide includes post-scanner repeat/state-heavy and many-definition profiles.\nStart expensive repeat cases with `--counts=250,1000 --warmup-count=250`;\nstate-overlay controls and separate native phases help identify the next\noptimization without running an unbounded matrix. Native CPU samples are not\nWASM allocation measurements, and no production rendering behavior is changed.\n\nThe guide also includes an opt-in native allocation baseline and a fresh-process\nmatrix command: `node crates/microsoft-fast-build/benches/profile-allocations.mjs\n--output=/tmp/fast-allocations.json` from the repository root. Its counters are\ndevelopment-only Rust tooling, not part of the npm CLI or WASM; native peak\nnewly-live heap is not process RSS.\n\n### Missing or omitted state\n\nState is optional. When `--state` is omitted and no `state` path is provided by config, `fast build` does not look for `state.json`; rendering uses an empty object (`{}`). An explicit `--state` path, or a `state` path from config, must exist or the command exits with an error.\n\n> **Breaking change:** Earlier versions implicitly loaded `state.json` from the current working directory when `--state` was omitted. To use a state file, pass `--state=state.json` or set `\"state\": \"state.json\"` in `fast-build.config.json`.\n\nWhen a binding value is not present in state:\n\n- Content bindings render nothing, including unresolved dot paths: `

{{foo.bar}}

` becomes `

`.\n- Attribute bindings omit the entire attribute, including unresolved dot paths: `
` becomes `
`.\n- `` treats a missing list binding, including unresolved dot paths, as an empty array and renders zero iterations. If the binding is present but is not an array, rendering still errors.\n\nExplicit `null` also omits an attribute, even in an interpolated attribute\nvalue. Empty strings remain present. Known HTML boolean attributes bound to\nJSON booleans use presence/absence; ordinary attributes (including ARIA)\nretain textual booleans. Use `?name` for browser-side truthy/falsy bindings.\nAuthor bindings resolving to absence still override template-host defaults.\nThese intentional output changes are described in the\n[plugin migration guide](./docs/migration/plugin-integrations.md).\n\n### APIs for build-time plugins\n\nImport the actual exported WASM subpath; do not slice rendered host HTML:\n\n```js\nimport {\n parse_f_templates,\n render_shadow_root,\n} from \"@microsoft/fast-build/wasm/microsoft_fast_build.js\";\n\nconst definitions = JSON.parse(parse_f_templates(templateHtml));\nconst templates = Object.fromEntries(\n definitions.filter(definition => definition.name !== null)\n .map(definition => [definition.name, definition]),\n);\nconst shadowRootHtml = render_shadow_root(\n \"my-card\", JSON.stringify(templates), JSON.stringify(componentState),\n);\n```\n\nThe result is the complete DSD `