Propose first-class oxlint and oxfmt support in Nx

[gperdomor]

Summary

This proposal requests official support for oxlint and oxfmt within the Nx ecosystem. Similar to the current @nx/eslint integration, official support would include project inference, automated configuration, and specialized executors that take advantage of the performance benefits of the Rust-based oxc toolchain.

Motivation

As monorepos grow, linting and formatting become significant CI bottlenecks. While Nx effectively mitigates this through caching and affected commands, the raw execution time of Node.js-based tools like ESLint and Prettier remains a fundamental constraint.

Three primary factors make official support timely:

1. Performance at scale

Benchmarks show that oxlint is 50-100x faster than ESLint. In a real-world monorepo environment with 5,360 files, oxlint completes in 1.3 seconds compared to 147 seconds for ESLint — a 113x speedup. Similarly, oxfmt provides a 30-35x performance increase over Prettier while maintaining 100% compatibility with Prettier's JS/TS conformance tests. Official integration would allow Nx users to reclaim significant CI time and improve the developer experience during local pre-commit hooks.

2. Rust-based toolchain alignment

The Nx ecosystem is already shifting toward high-performance Rust tooling. Nx has long supported SWC as a first-class compiler option, and integration for Rolldown is on the horizon. Adding oxc-based tools (oxlint and oxfmt) fits this trajectory perfectly. Providing a unified Rust-powered stack for compilation, linting, and formatting ensures the Nx toolchain remains the fastest available for modern TypeScript development.

3. Simpler configuration

ESLint configuration, particularly the transition to flat configs and the management of complex plugin ecosystems, involves significant ceremony. oxlint provides 756 built-in rules (including 59/61 from typescript-eslint) with no Node.js overhead. It operates as a standalone binary that requires less maintenance and fewer dependencies than the traditional ESLint/Prettier setup. Official Nx support would allow for a "zero-config" experience through project inference.

Proposal

We propose the introduction of a new plugin, or an expansion of existing capabilities, to include:

1. Project Inference: A CreateNodesV2 implementation that detects .oxlintrc.json or oxlint.config.ts and automatically adds a lint target to the project.
2. oxfmt Executor: A dedicated formatter executor that replaces or augments nx format:check and nx format:write. This would include a migration path from existing .prettierrc files using oxfmt --migrate prettier.
3. Generator Support: Updates to existing workspace and library generators to allow users to select oxlint and oxfmt as their default linter and formatter during project initialization.
4. Integrated Caching: Pre-configured task definitions that correctly handle cacheableOperations and inputs for oxc-based tasks.

Why Official Support Now?

When issue #21384 was previously discussed, the recommendation was to rely on community plugins. However, the landscape has changed significantly:

• Stability and Maturity: oxlint is now at v1.62.0 with stable weekly releases. oxfmt has achieved 100% Prettier compatibility for JS/TS and is used by major projects like typescript-eslint.
• Industry Adoption: Production users now include Sentry, Cloudflare, PostHog, and Elastic (Kibana). The backing of VoidZero Inc. (Evan You) ensures long-term maintenance and alignment with other modern tools like Vite and Rolldown.
• The "Format" Gap: The community nx-oxlint plugin exists but lacks formatter support and deep integration with Nx's core formatting utilities. Official support would ensure that nx format commands can leverage oxfmt's speed across the entire workspace.

Prior Art

• @nx/eslint: The existing ESLint plugin provides the blueprint for inference and executor patterns.
• Biome discussions: Issue Nx Release forces Prettier and has no way to disable, breaking biome builds #30403 highlighted demand for faster tooling, but oxc offers a more compatible migration path for teams on Prettier — oxfmt is explicitly designed as a drop-in replacement with a built-in migration tool.
• nx-oxlint: A community plugin (v0.1.1, 36 stars) that demonstrates feasibility but lacks the resources to keep pace with the full oxc suite or Nx's evolving plugin API.

Migration Path

A phased approach:

1. Opt-in formatting: Introduce oxfmt as an alternative backend for nx format.
2. Side-by-side linting: Allow oxlint to run alongside ESLint for correctness rules, eventually providing a generator to migrate eslint.config.mjs rules to .oxlintrc.json.
3. Default tooling: Offer oxc-based tools as the default for new workspaces.

References

• oxc project
• oxlint benchmarks
• oxfmt benchmarks
• typescript-eslint oxfmt migration (Feb 2026)
• Nx Issue #21384 — original oxlint request
• Community plugin: nx-oxlint