English for Oxlint Developers

Oxlint conversations focus on speed claims and migration caution in roughly equal measure, so the vocabulary leans on terms that let a team discuss both the performance win and the rule-coverage gap honestly.

Key Vocabulary

Rule parity — the degree to which Oxlint implements the same lint rules as an equivalent ESLint configuration, a key factor in deciding whether a migration is safe. “We’re not fully migrating yet — rule parity with our custom ESLint config is only around eighty percent, and the missing rules catch real bugs.”

Multithreaded linting — Oxlint’s default behavior of linting files across multiple CPU cores simultaneously, contributing heavily to its speed advantage over single-threaded linters. “On this monorepo, multithreaded linting is the difference between a two-minute lint step and a fifteen-second one.”

Dual-linting — running Oxlint and ESLint together during a transition period, using Oxlint for fast feedback and ESLint for rules Oxlint doesn’t yet cover. “We’re dual-linting for now — Oxlint runs on every save, ESLint still runs in CI to catch the custom rules Oxlint doesn’t implement.”

Zero-config defaults — the set of sensible lint rules Oxlint enables out of the box, intended to catch common bugs without requiring a configuration file at all. “We didn’t write a config — the zero-config defaults already flagged the unused variable and the unreachable code.”

Plugin gap — the set of ESLint plugins (framework-specific, style-related) that don’t yet have an Oxlint equivalent, which usually determines whether full migration is currently possible. “The plugin gap is the blocker here — our accessibility plugin has no Oxlint equivalent yet, so ESLint stays in the pipeline.”

Common Phrases

• “What’s our rule parity looking like for the custom rules we actually rely on, not just the defaults?”
• “Is multithreaded linting actually kicking in here, or are we bottlenecked on I/O instead?”
• “Should we dual-lint for now, or is the plugin gap small enough to migrate fully?”
• “Are the zero-config defaults catching what we need, or do we still need a config file?”
• “Is this rule missing because of a genuine plugin gap, or did we just forget to enable it?”

Example Sentences

Debugging a missed lint error: “This bug should have been caught in CI — turns out it’s a plugin gap, the rule that would have flagged it only exists in an ESLint plugin we haven’t found an Oxlint equivalent for.”

Explaining a migration decision: “We’re dual-linting rather than switching outright because rule parity isn’t there yet for our security-focused ESLint rules — losing those isn’t worth the speed gain.”

Reviewing a pull request: “Run this through both linters before merging — Oxlint will catch it fast locally, but let’s confirm ESLint’s stricter rule set doesn’t flag something Oxlint missed.”

Professional Tips

• Bring up rule parity specifically, not just “does it work,” when a teammate proposes full migration — it’s the substantive question, and vague reassurance isn’t enough.
• Use dual-linting to describe a considered transition strategy, not indecision — it signals you’re managing risk deliberately.
• Reference the plugin gap by naming the specific missing plugin, not “some rules are missing” — specificity makes the migration blocker concrete and actionable.
• Credit multithreaded linting as the speed mechanism when explaining benchmarks, rather than a vague “it’s written in Rust.”

Practice Exercise

1. Explain what “rule parity” means and why it matters before a full ESLint-to-Oxlint migration.
2. Describe a scenario where dual-linting is the right interim strategy.
3. Write a sentence identifying a specific plugin gap that would block a team’s migration.