feat(linter/plugins): add oxlint-plugin-eslint package#20009
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
oxlint-plugin-eslint packageoxlint-plugin-eslint package
…ble` (#20008) While working on #20009, discovered than many of ESLint's built-in rules define `rule.meta.fixable` as `null`. Since this is clearly an established pattern, correct TS types to accept `null`. Also accept `undefined`, as we do pretty much everywhere else that we accept `undefined`. Both `null` and `undefined` were already handled at runtime. This just makes that support "official" in the TS types.
3f508fa to
4bc84b1
Compare
5130b4e to
5e449b4
Compare
There was a problem hiding this comment.
Pull request overview
Adds a new oxlint-plugin-eslint npm package that exposes ESLint core rules as an Oxlint JS plugin, with lazy-loaded rule implementations and eagerly-available rule meta for plugin registration.
Changes:
- Introduces a generator (
generate-plugin-eslint.ts) and build pipeline updates to produceoxlint-plugin-eslintoutputs (index.js+ per-rule CJS files). - Adds a new npm package (
npm/oxlint-plugin-eslint) and wires it into release/versioning configuration. - Adds an end-to-end fixture to validate loading and running ESLint rules via Oxlint’s JS plugin mechanism.
Reviewed changes
Copilot reviewed 15 out of 16 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| pnpm-lock.yaml | Adds serialize-javascript and its types for meta serialization in the generator. |
| oxfmtrc.jsonc | Excludes new fixture files from formatting. |
| oxc_release.toml | Includes the new package in oxlint release version bumping. |
| npm/oxlint-plugin-eslint/package.json | Defines the new plugin package metadata and publish file list. |
| npm/oxlint-plugin-eslint/README.md | Documents installation and config usage for the new plugin. |
| npm/oxlint-plugin-eslint/CHANGELOG.md | Adds a placeholder changelog file. |
| apps/oxlint/tsdown.config.ts | Adds tsdown build outputs for oxlint-plugin-eslint (index + per-rule entries). |
| apps/oxlint/test/fixtures/plugin_eslint/* | Adds an e2e fixture and snapshot validating plugin behavior. |
| apps/oxlint/src-js/plugin-eslint/index.ts | Adds the plugin entrypoint that exports { meta, rules }. |
| apps/oxlint/scripts/generate-plugin-eslint.ts | Generates wrapper rule files + a lazy/eager rules index with serialized meta. |
| apps/oxlint/scripts/build.ts | Runs plugin generation and cleans the new dist directory before building. |
| apps/oxlint/package.json | Adds generator dependencies (serialize-javascript + types). |
| apps/oxlint/.gitignore | Ignores generated sources and new dist output directory. |
| .github/workflows/release_apps.yml | Copies and publishes the new npm package as part of the release workflow. |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
5e449b4 to
15c483c
Compare
b7d0453 to
4127827
Compare
|
Fixed merge conflicts and bumped version to 1.52.0 to match Oxlint. |
Merge activity
|
Closes #19746. Add `oxlint-plugin-eslint` plugin which exports all ESLint's built-in rules as a JS plugin which can be used with Oxlint. The code for rules is lazy-loaded on first use, so just using the plugin doesn't load the code for all the rules, only the ones which the user actually uses. However, the `meta` property of each rule is provided eagerly, so that `registerPlugin` in Oxlint can load the plugin without triggering the getters which lazy-load rule code. All ESLint's rule code is bundled into this plugin package, so the package has no dependencies. This has a few advantages: 1. We control the version of ESLint which the rules are taken from. 2. Avoids "works on my machine" unreproducible bug reports due to differing ESLint versions. 3. Avoids relying on ESLint's `eslint/use-at-your-own-risk` export, which could change without warning. At present, the plugin contains *all* ESLint's rules, including ones which are natively implemented in Oxlint. We might choose to scale it back to include only the rules which Oxlint doesn't natively implement. But then we need to consider what happens when we implement more rules in future: Do they disappear from this package without warning? Would that be considered a breaking change? If it would, how long do we keep them in this package? I propose that in the interests of getting this useful feature released without having to decide all these issues, we just go with it as is for now. JS plugins are not yet stable, so at present we can still make changes later on if we need to, without breaking any promises.
4127827 to
fe3b32e
Compare
# Oxlint ### 🚀 Features - 04a5ce0 oxlint: Support `vite.config.ts` `.lint` field (#20214) (leaysgur) - 1735215 linter: Implement `react/no-clone-element` rule. (#20129) (connorshea) - 68e6f6f linter: Implement `react/no-react-children` rule. (#20104) (connorshea) - fe3b32e linter/plugins: Add `oxlint-plugin-eslint` package (#20009) (overlookmotel) ### 🐛 Bug Fixes - 05f6a09 linter/no-inline-comments: Deserialize rule options with serde (#20207) (camc314) - c7eb09d linter/default-case: Deserialize rule options with serde (#20206) (camc314) - f85e16c linter/plugins: Fix types for visitor compilation (#20203) (overlookmotel) - 44e24e0 linter/exhaustive-deps: Ignore type-only typeof deps (#20201) (camc314) - 0b04998 linter/no-fallthrough: Deserialize rule options with serde (#20192) (camc314) - a1031cb linter/new-cap: Deserialize rule options with serde (#20161) (camc314) - ad27fd6 linter: Add help messages to import plugin diagnostics (#20158) (John Costa) - 1340307 linter/plugins: Ensure `after` hooks always run (#20167) (overlookmotel) - c4812ec linter/plugins: Reset visitor compilation state if error during compilation (#20166) (overlookmotel) - 887eecc linter/plugins: Add license notice to `oxlint-plugin-eslint` package (#20164) (overlookmotel) - e1713a4 linter/plugins: Include common chunks in `oxlint-plugin-eslint` package (#20163) (overlookmotel) - a9acb2b linter: Check `globals` entry for `no-undef`, only check es2026 globals for `no-extend-native` and `no-constant-binary-expression` (#20089) (Sysix) - 5559f0d linter/no-unused-vars: `reportUsedIgnorePattern` should not report used rest siblings (#20108) (Don Isaac) - de7c0e2 linter/plugins: Correct error message for `markVariableAsUsed` (#20152) (overlookmotel) ### ⚡ Performance - 3a86427 linter/plugins: Pre-populate cache of `EnterExit` objects at startup (#20194) (overlookmotel) - d243391 linter/plugins: Replace arrays with `Uint8Array`s (#20190) (overlookmotel) - 8742f8b linter/plugins: Pre-populate cache of `VisitProp` objects (#20189) (overlookmotel) - 3061acb linter/plugins: Pre-populate cache of `EnterExit` objects (#20187) (overlookmotel) - c73912b linter/plugins: Free visit functions earlier (#20186) (overlookmotel) - d9f8ff4 linter/plugins: Faster reset of visitor state (#20185) (overlookmotel) - 42aff15 oxlint/lsp: Avoid computing diagnostics for non invoked code actions requests (#20080) (Sysix) ### 📚 Documentation - a080650 linter/plugins: Fix documentation of visitor compilation (#20202) (overlookmotel) - 542a04a linter: Add a link to the cyclomatic complexity Wikipedia article in `eslint/complexity` (#20174) (connorshea) # Oxfmt ### 🚀 Features - 95943aa oxfmt: Support `vite.config.*` `.fmt` field (#20197) (leaysgur) - 172fc07 oxfmt: .js/.ts config file support (#20135) (leaysgur) ### 🐛 Bug Fixes - e483569 oxfmt: Avoid double-escaping in css-in-js (#20211) (leaysgur) Co-authored-by: leaysgur <6259812+leaysgur@users.noreply.github.com>

Closes #19746.
Add
oxlint-plugin-eslintplugin which exports all ESLint's built-in rules as a JS plugin which can be used with Oxlint.The code for rules is lazy-loaded on first use, so just using the plugin doesn't load the code for all the rules, only the ones which the user actually uses. However, the
metaproperty of each rule is provided eagerly, so thatregisterPluginin Oxlint can load the plugin without triggering the getters which lazy-load rule code.All ESLint's rule code is bundled into this plugin package, so the package has no dependencies. This has a few advantages:
eslint/use-at-your-own-riskexport, which could change without warning.At present, the plugin contains all ESLint's rules, including ones which are natively implemented in Oxlint.
We might choose to scale it back to include only the rules which Oxlint doesn't natively implement. But then we need to consider what happens when we implement more rules in future: Do they disappear from this package without warning? Would that be considered a breaking change? If it would, how long do we keep them in this package?
I propose that in the interests of getting this useful feature released without having to decide all these issues, we just go with it as is for now. JS plugins are not yet stable, so at present we can still make changes later on if we need to, without breaking any promises.