Skip to content

feat(linter/plugins): add oxlint-plugin-eslint package#20009

Merged
graphite-app[bot] merged 1 commit intomainfrom
om/03-04-linter_introduce_oxlint-plugin-eslint_package
Mar 9, 2026
Merged

feat(linter/plugins): add oxlint-plugin-eslint package#20009
graphite-app[bot] merged 1 commit intomainfrom
om/03-04-linter_introduce_oxlint-plugin-eslint_package

Conversation

@overlookmotel
Copy link
Member

@overlookmotel overlookmotel commented Mar 4, 2026

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.

Copy link
Member Author

overlookmotel commented Mar 4, 2026


How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

  • 0-merge - adds this PR to the back of the merge queue
  • hotfix - for urgent hot fixes, skip the queue and merge this PR next

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.

@github-actions github-actions bot added A-linter Area - Linter A-cli Area - CLI A-linter-plugins Area - Linter JS plugins labels Mar 4, 2026
@overlookmotel overlookmotel marked this pull request as ready for review March 4, 2026 21:56
@overlookmotel overlookmotel requested a review from camc314 as a code owner March 4, 2026 21:56
Copilot AI review requested due to automatic review settings March 4, 2026 21:56
@overlookmotel overlookmotel changed the title linter: introduce oxlint-plugin-eslint package feat(linter/plugins): add oxlint-plugin-eslint package Mar 4, 2026
@github-actions github-actions bot added the C-enhancement Category - New feature or request label Mar 4, 2026
@graphite-app graphite-app bot changed the base branch from om/03-04-fix_linter_plugins_allow_null_and_undefined_for_rule.meta.fixable_ to graphite-base/20009 March 4, 2026 22:00
graphite-app bot pushed a commit that referenced this pull request Mar 4, 2026
…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.
@graphite-app graphite-app bot force-pushed the graphite-base/20009 branch from 3f508fa to 4bc84b1 Compare March 4, 2026 22:08
@graphite-app graphite-app bot force-pushed the om/03-04-linter_introduce_oxlint-plugin-eslint_package branch from 5130b4e to 5e449b4 Compare March 4, 2026 22:08
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 produce oxlint-plugin-eslint outputs (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

@graphite-app graphite-app bot changed the base branch from graphite-base/20009 to main March 4, 2026 22:08
@graphite-app graphite-app bot force-pushed the om/03-04-linter_introduce_oxlint-plugin-eslint_package branch from 5e449b4 to 15c483c Compare March 4, 2026 22:09
@overlookmotel overlookmotel force-pushed the om/03-04-linter_introduce_oxlint-plugin-eslint_package branch 3 times, most recently from b7d0453 to 4127827 Compare March 9, 2026 11:06
@overlookmotel
Copy link
Member Author

Fixed merge conflicts and bumped version to 1.52.0 to match Oxlint.

@camc314 camc314 added the 0-merge Merge with Graphite Merge Queue label Mar 9, 2026
Copy link
Contributor

camc314 commented Mar 9, 2026

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.
@graphite-app graphite-app bot force-pushed the om/03-04-linter_introduce_oxlint-plugin-eslint_package branch from 4127827 to fe3b32e Compare March 9, 2026 17:22
@graphite-app graphite-app bot merged commit fe3b32e into main Mar 9, 2026
21 checks passed
@graphite-app graphite-app bot deleted the om/03-04-linter_introduce_oxlint-plugin-eslint_package branch March 9, 2026 17:34
@graphite-app graphite-app bot removed the 0-merge Merge with Graphite Merge Queue label Mar 9, 2026
leaysgur added a commit that referenced this pull request Mar 11, 2026
# 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-cli Area - CLI A-linter Area - Linter A-linter-plugins Area - Linter JS plugins C-enhancement Category - New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

linter: introduce oxlint-plugin-eslint

3 participants