English for Biome Linter Developers

Biome has emerged as a fast, all-in-one alternative to ESLint and Prettier, combining linting and formatting into a single Rust-based toolchain. If you work with Biome on an international team, you’ll need clear English to discuss rule configuration, migration decisions, and code quality standards. This guide covers the core vocabulary for Biome developers.

Key Vocabulary

Linter — a static analysis tool that flags problematic patterns in code, such as unused variables or unsafe comparisons. “Biome’s linter caught an unused import that our previous ESLint config had accidentally disabled.”

Formatter — a tool that automatically rewrites code to follow consistent style rules, such as indentation and quote style. “We run Biome’s formatter as a pre-commit hook so every file follows the same style, regardless of who wrote it.”

Rule — an individual check within the linter that enforces one specific coding convention or catches one class of bug. “We enabled the noUnusedVariables rule at the error level, so the build fails if anyone leaves in an unused variable.”

Severity level — the classification of a rule’s violations, typically off, warn, or error, controlling whether it blocks a build. “We set most style rules to warn and correctness rules to error, so stylistic nitpicks don’t block a merge.”

Recommended ruleset — a curated default set of rules that Biome enables out of the box, intended to represent sensible defaults. “We started from the recommended ruleset and only turned off two rules that conflicted with our existing codebase conventions.”

Migration — the process of converting an existing ESLint or Prettier configuration to Biome’s equivalent configuration. “The migration command mapped about 90% of our ESLint rules automatically — we manually reviewed the rest.”

Organize imports — a Biome feature that automatically sorts and groups import statements according to configured conventions. “We enabled organize imports so pull requests don’t get cluttered with unrelated import-reordering diffs.”

Diagnostic — the message Biome produces when a rule is violated, including the location, explanation, and often a suggested fix. “The diagnostic pointed directly at the line with the unsafe == comparison and suggested switching to ===.”

Discussing Configuration Decisions

• “We chose to keep line width at 100 characters instead of Biome’s default of 80, to match our team’s existing convention.”
• “We disabled the noExplicitAny rule temporarily while we finish migrating our legacy modules to stricter types.”
• “Organize imports runs automatically on save, so we rarely see import-ordering issues in code review anymore.”

Talking About Migration and Adoption

• “The migration from ESLint cut our lint step from twelve seconds to under one second, since Biome is written in Rust.”
• “We ran Biome in parallel with ESLint for two weeks before fully switching, to catch any rule mismatches.”
• “A few custom ESLint plugins had no Biome equivalent, so we kept ESLint just for those specific checks.”

Professional Tips

1. Explain severity levels in terms of workflow impact. “This is a warning, not a blocker” reassures reviewers who see new diagnostics appear after enabling a rule.
2. Document any rules you’ve deliberately disabled. Future contributors need to know it was a decision, not an oversight.
3. Frame speed improvements in concrete terms. “Lint went from twelve seconds to under one” is more persuasive to stakeholders than “it’s faster.”

Practice Exercise

1. Explain to a teammate, in 3-4 sentences, the difference between a linter and a formatter.
2. Write a short explanation (4-5 sentences) of why your team set certain rules to warn instead of error.
3. Describe, in plain English, what changed in your team’s workflow after migrating from ESLint and Prettier to Biome.