feat(linter): add setup-oxlint-bridge generator for ESLint/Oxlint coexistence#35114
Open
benpsnyder wants to merge 3 commits intonrwl:masterfrom
Open
feat(linter): add setup-oxlint-bridge generator for ESLint/Oxlint coexistence#35114benpsnyder wants to merge 3 commits intonrwl:masterfrom
benpsnyder wants to merge 3 commits intonrwl:masterfrom
Conversation
…xistence Add a new generator `@nx/eslint:setup-oxlint-bridge` that injects the JITI bridge into existing ESLint flat configs, enabling eslint-plugin-oxlint to dynamically disable ESLint rules already handled by Oxlint. The generator: - Installs eslint-plugin-oxlint and jiti as devDependencies - Injects JITI-based loading of oxlint.config.ts into eslint.config.mjs/cjs - Adds reportUnusedDisableDirectives: 'off' to prevent false warnings - Appends ...oxlint.buildFromOxlintConfig() for precise rule deduplication - Supports both ESM and CJS flat config formats Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
✅ Deploy Preview for nx-docs canceled.
|
✅ Deploy Preview for nx-dev canceled.
|
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
| `const { createJiti } = require('jiti');`, | ||
| '', | ||
| `const jiti = createJiti(__filename);`, | ||
| `const oxlintConfig = jiti.import('${oxlintConfigPath}', { default: true });`, |
Contributor
There was a problem hiding this comment.
Invalid JITI API usage in CJS path. The jiti.import() method does not accept { default: true } as a second parameter to extract the default export. This will cause a runtime error when the generator is run on a CJS ESLint config.
The ESM version (lines 115-117) correctly uses .default to extract the default export:
const oxlintConfig = (await jiti.import('${oxlintConfigPath}')).default;The CJS version should match this pattern:
const oxlintConfig = jiti.import('${oxlintConfigPath}').default;This bug will break the generator for any workspace using CommonJS ESLint configs (eslint.config.cjs).
Suggested change
| `const oxlintConfig = jiti.import('${oxlintConfigPath}', { default: true });`, | |
| `const oxlintConfig = jiti.import('${oxlintConfigPath}').default;`, |
Spotted by Graphite
Is this helpful? React 👍 or 👎 to let us know.
FrozenPandaz
added
the
priority: low
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Current Behavior
When migrating from ESLint to Oxlint in an Nx workspace, there is no built-in way to make ESLint aware of which rules Oxlint already covers. Users must manually configure
eslint-plugin-oxlint, set up JITI to load TypeScript-basedoxlint.config.tsfrom ESLint's.mjsconfig, disablereportUnusedDisableDirectives, and usebuildFromOxlintConfig()instead of the less preciseflat/recommendedpreset. This is error-prone and undocumented in Nx.Expected Behavior
A new generator
nx g @nx/eslint:setup-oxlint-bridgeautomates the ESLint-side setup for Oxlint coexistence:eslint-plugin-oxlintandjitias devDependencieseslint.config.mjs(or.cjs) so ESLint can loadoxlint.config.tsat runtimereportUnusedDisableDirectives: 'off'to prevent false warnings from oxlint'seslint-disablecomments...oxlint.buildFromOxlintConfig(oxlintConfig)to precisely disable only the ESLint rules that oxlint already handles--oxlintConfigPathfor non-standard config locationsThis follows the community-standard pattern used by AnalogJS alpha and documented by
eslint-plugin-oxlint. It complements the@nx/oxlintplugin work in #34838 and nx-labs#441 — those PRs build the Oxlint side, this PR builds the ESLint bridge for coexistence during migration.Changes
packages/eslint/generators.json— Registersetup-oxlint-bridgegeneratorpackages/eslint/src/utils/versions.ts— AddeslintPluginOxlintVersion(^1.57.0) andjitiVersion(^2.6.1)packages/eslint/src/generators/setup-oxlint-bridge/— Generator implementation, schema, types, and 12 unit tests covering ESM/CJS injection, idempotency, error cases, and config preservationRelated Issue(s)
Complements #34838 and nx-labs#441
#35111