Biome makes formatting and linting one fast, reviewable policy

01A toolchain, not just a faster formatter

The Biome repository describes a toolchain for web projects, implemented in Rust and delivered through a command-line interface plus language server. Its formatter handles supported source formats without requiring code execution, while the linter analyzes common correctness, complexity, accessibility, security, and style concerns. The check command can bring formatting, linting, and import-related actions into one pass. This shared foundation is the project's main architectural advantage over a folder of separately configured utilities.

Consolidation reduces configuration drift, but it also changes how a team should evaluate the tool. A benchmark on one file does not show whether the repository's important rules exist or whether framework syntax parses correctly. Inventory the current formatter options, lint plugins, ignores, generated paths, editor extensions, and CI invocations first. Biome can replace a large common center without reproducing every edge extension. A successful migration is one where the remaining exceptions are small, named, and intentionally owned.

02The formatter makes consistency intentionally boring

A formatter is most effective when developers stop discussing whitespace in review. Biome's formatter is opinionated but configurable around practical choices such as line width, indentation, quotes, and trailing commas. It supports JavaScript, TypeScript, JSX, JSON and additional web-oriented syntax documented by the project. Because it parses the file, it can format structure rather than applying a fragile sequence of text substitutions.

Formatter migrations should be isolated from semantic work. Run the formatter across a clean branch, commit that mechanical change on its own, and ask reviewers to inspect configuration plus representative files rather than every moved token. Long-lived feature branches may need to merge before the bulk pass to reduce conflicts. If exact Prettier output is part of snapshots, generated documentation, or downstream tooling, compare those artifacts before switching. Consistency matters more than making two formatters produce identical text.

03Lint rules should protect product behavior

Biome's linter groups rules by purpose and severity, with recommended rules providing a maintained baseline. The useful rules catch mistakes that compile successfully: suspicious comparisons, unreachable branches, unsafe patterns, incorrect Hook usage, accessibility omissions, and confusing control flow. A repository should start from the recommended set, then enable additional rules because a concrete class of defect matters. Copying every available rule into an error policy makes upgrades noisy and encourages suppression rather than understanding.

Each diagnostic needs an owner and a response. An error should block CI because the condition is unacceptable, while a warning should lead to work rather than become permanent background color. Suppressions belong on the narrowest line or file and should state why the rule does not apply. Generated and vendored code should usually be excluded at the configuration boundary. Linting is most trustworthy when it focuses human attention instead of claiming to prove correctness.

04Safe fixes and unsafe fixes are different operations

Biome can apply fixes and organize parts of the source automatically. The project distinguishes fixes that are expected to preserve semantics from unsafe fixes that may change behavior. That distinction should flow into scripts and automation. A developer may choose an unsafe fix while reviewing a local diff, but a background formatter, save action, or routine CI repair should not make the same decision without scrutiny.

Even safe fixes deserve a diff, particularly during the first rollout or after a major upgrade. Parsers and fixers operate on syntax, while a repository may have generated conventions or tools that read source text in unexpected ways. Keep write commands separate from check-only commands and make CI diagnostic by default. If a bot prepares fixes, have it open a bounded change rather than push directly to a protected branch. Automation is useful when it produces evidence a reviewer can understand.

• Use check-only commands as the merge gate and reserve write commands for local or reviewable automation.
• Do not enable unsafe fixes globally without inspecting each rule category that can change code.
• Run tests and type checks after bulk fixes because lint success is not runtime evidence.

05Configuration has to follow repository boundaries

Biome v2 added stronger support for nested configuration and monorepos. That helps a workspace share a common baseline while allowing a package with different source types or generated output to refine it. The design still needs discipline. A configuration should have a clear root, predictable inheritance, and as few exceptions as possible. When the same rule changes severity across packages, document whether that reflects a migration stage or a permanent domain difference.

Ignore behavior is part of the correctness story. Build output, generated clients, fixtures, migrations, and vendored code may need different treatment, but a broad directory pattern can also hide handwritten source accidentally. Test configuration from the repository root and from package working directories used by editors or task runners. CI should report the file set it checked when debugging a mismatch. A fast tool that silently skips the wrong package creates a reassuring result with no coverage.

06The editor and CI must run the same policy

Biome's language server can provide formatting, diagnostics, and code actions while a developer edits. Immediate feedback is one reason an integrated tool feels faster even before measuring command time. The editor should use the workspace binary and repository configuration rather than an unrelated global version. Save actions also need an explicit policy: formatting on save is predictable, while broad fix-on-save behavior can be surprising if it includes semantic changes.

CI is the authoritative second line. Run the pinned binary on a clean checkout and fail on the agreed diagnostic severities. Avoid a workflow where a global command silently upgrades or downloads a newer release. In a large workspace, caching and changed-file optimization can reduce time, but the full repository should still run periodically to catch configuration or dependency effects. When local and CI results differ, compare version, current directory, environment, ignore files, and file enumeration before blaming the parser.

07Migration from ESLint and Prettier should preserve evidence

Biome provides migration commands for established configurations, but generated configuration is a starting point rather than a certification. Compare each important ESLint plugin and rule with Biome's support, especially framework, security, import, and organization-specific rules. Some tools may remain beside Biome temporarily. That is acceptable when the overlap is removed and each command has a defined purpose. Running two formatters on the same files is not acceptable because their outputs can fight indefinitely.

A practical sequence is check-only linting, a separate formatting commit, safe fixes, editor rollout, and then removal of redundant packages. Track the old and new diagnostic sets on a stable revision so a reduced error count is not mistaken for improved code. Run the full tests and type checker after the switch. Package scripts, pre-commit hooks, CI annotations, and contributor documentation must move together, otherwise the retired tool survives in one corner and continues to rewrite files.

08Licensing and the honest adoption decision

Biome is offered under a dual MIT or Apache-2.0 arrangement, with both license texts in the repository. That gives organizations familiar permissive choices while preserving the obligations of the selected license. Dependencies and distributed editor extensions should still be covered by an ordinary software inventory. The public repository, documentation, releases, and rule reference provide a strong source trail for evaluating changes rather than relying on a hosted black box.

Choose Biome when its maintained rule set covers the defects your team cares about and one tool can retire meaningful configuration. Keep ESLint or another specialist where a custom rule is genuinely part of product safety. The project's expanding language and cross-file capabilities are promising, but future plans should not be counted as present support. Pin the version, review major migrations, and judge success by stable policy, useful diagnostics, and reduced maintenance, not by the number of packages removed.