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.

Navigating Nuance: Addressing Feedback Beyond Literal Translation

Biome Linter, like many sophisticated tools, thrives on precision in communication. For developers who are increasingly working collaboratively across borders – and for anyone striving to communicate effectively within a technical team – understanding the intent behind feedback is just as crucial as knowing the words themselves. It’s easy to translate phrases literally, but that often misses the subtle cues of professional English used in code reviews, Slack discussions, or pull request descriptions. The goal isn’t simply to fix what’s “wrong” according to a direct translation; it’s about conveying a clear understanding and proposing solutions constructively. A common pitfall is taking criticism at face value – for example, receiving a comment like “This doesn’t follow the style guide” without context. What specifically does the style guide require? Is it spacing, indentation, or variable naming conventions? Asking clarifying questions demonstrates engagement and helps you address the root cause of the issue. Similarly, when explaining your reasoning during a review, avoid simply stating “I did this because…” – instead, articulate why that approach was chosen, referencing relevant documentation or design decisions.

Furthermore, phrasing matters significantly in technical discussions. Using overly formal language can feel detached and less collaborative. Aim for clarity and directness while maintaining respect. Instead of saying “Please ensure the implementation adheres to the established best practices,” a more approachable version would be “Could you review this to confirm it aligns with our team’s style guidelines?” This subtle shift in wording fosters a more open dialogue. Crucially, remember that feedback isn’t necessarily an accusation; it’s often an opportunity for learning and improvement. Framing your responses accordingly – acknowledging the reviewer’s perspective and demonstrating a willingness to adapt – is paramount. Recognizing the potential for misinterpretation, especially when communicating complex technical concepts, allows you to proactively address misunderstandings before they escalate.

Finally, consider the impact of your writing on the overall flow of communication. Concise and well-structured pull request descriptions are vital, not just for reviewers but also for future developers maintaining the codebase. When documenting changes, focus on what was done, why it was done, and any potential implications. This proactive approach minimizes ambiguity and streamlines the onboarding process.

Here’s a simple example of using Biome Linter to highlight a formatting issue:

biome check --config biome.json .

This command will run the linter against your current directory, flagging stylistic inconsistencies based on your configured ruleset. The output will detail the specific violations and suggest corrections, which you can then address in your code or PR description.