/biome

name: biome
description: "Use Biome in .NET repositories that ship Node-based frontend assets and want a fast combined formatter-linter-import organizer for JavaScript, TypeScript, CSS, JSON, GraphQL, or HTML. USE FOR: biome.json or @biomejs/biome setup; fast frontend formatting and linting; replacing overlapping frontend style tools deliberately. DO NOT USE FOR: ESLint-only plugin coverage; runtime site audits such as headers, accessibility, or browser behavior. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made."
compatibility: "Requires a .NET repository with frontend assets managed through Node or a standalone Biome binary workflow; keep ownership explicit versus ESLint, Stylelint, and webhint."

Biome for Frontend Assets in .NET Repositories

Trigger On

• the repo has `biome.json`, `@biomejs/biome`, or the user asks for a faster all-in-one frontend formatter-linter stack
• the repo wants one tool for formatting, linting, and import organization across JS, TS, CSS, JSON, GraphQL, or HTML
• the team is comparing Biome against ESLint plus Prettier or wants to simplify the current stack

Do Not Use For

• repos that rely on ESLint plugins or framework-specific rules Biome does not cover yet
• runtime site audits such as headers, accessibility, and SEO; route that to `webhint`
• cases where a dedicated CSS or HTML tool is still the deliberate owner and no migration is requested

Inputs

• the nearest `AGENTS.md`
• `package.json`
• `biome.json` or `biome.jsonc`
• current ownership across ESLint, Prettier, Stylelint, and import ordering

Workflow

1. Decide ownership first:

• Biome as the main formatter and linter
• Biome only for formatting
• Biome in coexistence with ESLint for plugin gaps

2. Prefer a repo-local pinned install so CI and developer machines use the same version. 3. Generate `biome.json` only after confirming what the repo wants Biome to own. 4. Add repeatable scripts to `package.json`, for example:

• `biome check .`
• `biome check . --write`

5. Keep file ownership explicit:

• Biome can own formatting, linting, and import sorting
• webhint still owns site-runtime audits
• ESLint may stay for plugin-heavy cases the repo intentionally keeps

6. Start migrations with `check` and bounded folders before flipping the whole repo to `--write`. 7. Re-run the frontend build and tests after broad formatting or lint-fix passes.

Current Upstream Notes

• [Biome CLI `2.5.12`](https://github.com/biomejs/biome/releases/tag/%40biomejs/biome%402.5.12) fixes Astro expression parsing, nested JSX attribute sorting, Unicode stdin/stdout corruption, and repeated dependency scanning. Validate representative Astro/TSX files, Unicode input, and formatter idempotence before dropping workarounds.
• `noFloatingPromises` now handles cyclic imports and awaited Promise aliases more accurately; awaiting an array of Promises still leaves its elements unhandled. Use `Promise.all` or an explicit awaited loop when appropriate. New Nursery rules remain opt-in, including `useFlatMathMinMax`, `useModernMathApis`, `noThisOutsideOfClass`, `noVueDeprecatedScopedSlots`, and `noBunModules`.

• Biome CLI `2.5.11` includes the `2.5.8`-`2.5.10` rule and parser additions and adds Nursery rules for unsafe Astro `set:html` and undeclared CSS custom properties. Enable Nursery rules explicitly; do not treat a version update as permission to change the repository's lint policy.
• The release fixes Astro shorthand anchors, implicit fragments, void elements, and full HTML handling through `--stdin-file-path`; Vue template/CSS binding false positives; GraphQL naming trivia; and several type-inference performance paths. Re-run the repository's existing `biome check` and formatter-idempotence tests before removing suppressions or accepting churn.
• When `--stdin-file-path` is used, verify that the intended nested `biome.json` is selected and that ignored input produces the expected warning. Keep fixtures for Vue custom blocks, Svelte attachments, Tailwind class sorting, and non-ASCII diagnostic spans when those surfaces matter.
• Recent Biome changes also continue expanding CSS/SCSS, HTML accessibility, import sorting, watch mode, and upgrade-command surfaces; verify actual CLI ownership before replacing ESLint or Stylelint.

Bootstrap When Missing

1. Detect current state:

• `rg --files -g 'package.json' -g 'biome.json*'`
• `rg -n '"@biomejs/biome"|"eslint"|"prettier"|"stylelint"' --glob 'package.json' .`

2. Prefer a repo-local pinned install:

• `npm i -D -E @biomejs/biome`

3. Create config deliberately:

• `npx @biomejs/biome init`

4. Add repeatable commands to `AGENTS.md` and `package.json`, then verify with:

• `npx @biomejs/biome check .`
• `npx @biomejs/biome check . --write`

5. Return `status: configured` if Biome is now wired with explicit ownership, or `status: improved` if the existing setup was tightened. 6. Return `status: not_applicable` when the repo intentionally stays on ESLint-centered ownership and no migration or comparison was requested.

Handle Failures

• Missing-rule parity with specialized ESLint plugins is an ownership problem; keep ESLint for those files until the gap is intentionally closed.
• Overly broad `--write` runs can cause large churn; start with bounded folders or changed files first.
• Generated assets or vendored code should be excluded in `biome.json` before trusting the signal.
• If developers complain that Biome and ESLint disagree, define file ownership instead of running both broadly on the same surface by accident.

Deliver

• explicit Biome ownership and version pinning
• checked-in config and repeatable `check` commands
• a migration or coexistence plan versus ESLint and other frontend tools

Validate

• the chosen ownership model is documented
• CI and local runs use the same Biome version
• the target globs exclude ge