English for Oxc Developers

Oxc conversations mix two vocabularies — the general language of linters and parsers, and the performance-focused language of a Rust-based toolchain competing on speed — so being clear about which claim you’re making (correctness vs. speed) keeps the discussion useful.

Key Vocabulary

Parser (AST) — the component that reads raw JavaScript or TypeScript source and produces an Abstract Syntax Tree, the structure every other tool in the chain operates on. “The crash wasn’t in our lint rule at all — it was the parser failing on a newer syntax feature it didn’t yet support.”

Linter rule — a single check, such as no-unused-vars, that walks the AST looking for a specific pattern and reports a violation. “We disabled that rule project-wide because it was flagging a pattern we intentionally use, not because the rule itself was buggy.”

Rule set / plugin — a bundled collection of linter rules, often mirroring an existing ESLint plugin, that can be enabled or configured together. “Migrating meant mapping our existing ESLint plugin configuration onto the equivalent Oxc rule set, rule by rule.”

Transformer — the part of the toolchain responsible for converting modern syntax into a target-compatible output, similar in role to Babel but implemented natively. “The build error came from the transformer not yet supporting a proposal-stage syntax feature we were using.”

Throughput / cold start — performance terms describing how much code the tool processes per second and how quickly it starts up, the two numbers usually cited when comparing toolchains. “The real win for our CI pipeline wasn’t just throughput on a large run — it was the near-instant cold start on every small incremental lint.”

Common Phrases

• “Is this a parser limitation, or is our lint configuration actually wrong?”
• “Which rule is flagging this — do we know the exact rule ID?”
• “Is this a throughput problem, or is the slowness coming from cold start on every invocation?”
• “Does this rule set map directly onto our old ESLint plugin, or do we need custom rules?”
• “Is the transformer stable enough for this syntax yet, or should we hold off?”

Example Sentences

Explaining a migration decision: “We migrated our lint step to Oxc mainly for CI throughput — a full-repo lint went from twenty seconds to under two.”

Reporting a parser bug: “This isn’t a false positive from our rule — the parser is mis-reading a decorator pattern and producing the wrong AST node.”

Describing tooling trade-offs: “We kept ESLint for a few plugins that don’t have an Oxc equivalent yet, and run both in CI until the gap closes.”

Professional Tips

• Distinguish a parser bug from a linter rule bug explicitly — they require completely different fixes and often different bug trackers.
• Cite throughput and cold start separately when making a performance claim — a tool can win on one and lose on the other, and vague “it’s faster” statements invite pushback.
• Reference the exact rule ID when discussing a lint failure in a PR comment, not just “the linter is complaining.”
• When justifying a migration, name specific rule sets or plugins with no equivalent yet — it sets realistic expectations for reviewers.

Practice Exercise

1. Explain the difference between a parser bug and a linter rule bug.
2. Describe why cold start time matters separately from raw throughput.
3. Write a sentence justifying a tooling migration using a specific, measurable claim.