Formatter and Linter style ownership in Biome's shared configuration

The short answer

Assign a rule to the formatter when it only controls layout — indentation, line width, wrapping, spacing, quotes, semicolons, trailing commas. Assign it to the linter when it requires semantic judgment — unused variables, suspicious patterns, accessibility, correctness, or anything needing AST context. If a rule rewrites code deterministically without changing meaning, it belongs to the formatter; if it flags a possible defect, it belongs to the linter. Never let both tools own the same construct.

Decision criteria

• Behavior-neutral? If applying the rule can never change runtime semantics, it is formatter territory. Biome's formatter is designed to be safe to run blindly on save.
• Needs context? If the rule must understand scope, types, or control flow (e.g., unused imports vs. import ordering), it is a lint rule, even if its fix looks mechanical.
• Overlap? Pick exactly one owner. Prefer the formatter for pure whitespace/layout; keep the linter for anything that can catch defects. Do not enable a lint rule that rewrites or flags the same construct the formatter manages.

Resolving conflicts without losing correctness

When a lint rule fights formatter output, suppress narrowly, in this order of preference:

1. Disable the specific overlapping rule in biome.json, not the whole category. Turning off an entire lint group to silence one stylistic conflict also silences real defect checks.
2. Use targeted overrides scoped to the affected files, languages, or migration directories. Treat overrides as temporary seams and remove them when the transition finishes.
3. Reserve biome-ignore comments for genuinely exceptional lines. Scattered suppression comments during migration become permanent noise.

Keep biome.json as the single coordination point for formatter settings, linter rules, ignores, and per-language overrides — splitting ownership decisions across multiple files or editor configs is how drift starts.

{
  "formatter": { "indentStyle": "space" },
  "linter": {
    "rules": {
      "style": { "useConst": "error" },
      "suspicious": { "noExplicitAny": "off" }
    }
  },
  "overrides": [
    {
      "includes": ["legacy/**"],
      "linter": { "rules": { "correctness": { "noUnusedVariables": "warn" } } }
    }
  ]
}

Rule names and schema shape are version-sensitive — confirm against your installed Biome release (biome --version) before committing changes.

Verification during the transition

1. Run the formatter and linter separately on a clean tree, then run the combined biome check. Formatter output must not introduce lint failures.
2. Use CI-safe dry-run modes (biome ci or biome check without --write) so the build fails if formatting triggers correctness rules.
3. Build a small fixture file containing your known conflict cases and assert the expected owner: layout issues produce formatter-only diffs; correctness issues produce lint diagnostics.
4. Require that formatter-only changes produce zero test or type-check deltas. If a "format-only" commit breaks tests, a rule is mis-owned.
5. Verify ignore behavior: VCS ignores and Biome's own file inclusion are not identical — confirm generated, vendor, and fixture paths are excluded consistently for both tools.

One caveat worth flagging: if you move enforcement from the linter to the formatter, make sure CI actually runs the formatter in check mode — otherwise you have silently weakened the gate.