fix: Fix plugin scope determination logic by connorshea · Pull Request #402 · oxc-project/oxlint-migrate

connorshea · 2026-02-23T01:26:47Z

This change ensures that the plugin rules are migrated with the correct name (e18e/rule-name, not @e18e/rule-name). It also ensures that the plugin name that is used is correct.

It should migrate as "jsPlugins": ["@e18e/eslint-plugin"], but prior to this PR did not.

From what I understand, the reason it is e18e/rule-name despite the scoped plugin name is that it specifies the meta.name field here.

The Tanstack integration test is unchanged as it was already correct.

This also fixes using the usage of @eslint-react plugin. Fixes #377.

Generated with Claude Code, tested by me and confirmed as fixing the problem fully.

connorshea · 2026-02-23T01:49:39Z

src/jsPlugins.ts

+/**
+ * Resolves the npm package name for an ESLint plugin given its scope name.
+ *
+ * For scoped plugin names (starting with `@`), the mapping is unambiguous:
+ *   - `@scope`     -> `@scope/eslint-plugin`
+ *   - `@scope/sub` -> `@scope/eslint-plugin-sub`
+ *
+ * For non-scoped names, the npm package could follow either convention:
+ *   - `eslint-plugin-{name}` (e.g. `eslint-plugin-mocha`)
+ *   - `@{name}/eslint-plugin` (e.g. `@e18e/eslint-plugin`)
+ *
+ * We try to resolve both candidates against the installed packages and
+ * use the one that is actually present, falling back to the standard
+ * `eslint-plugin-{name}` convention when neither can be resolved.
+ */


This comment is entirely Claude's assumption, I'm pretty sure you could (though if you did, you're insane) have a non-scoped plugin like eslint-plugin-foo but set meta.name to @foo. But I have no idea if we care about supporting that edge-case for now.

connorshea · 2026-02-23T02:24:14Z

src/jsPlugins.ts

-const guessEslintPluginName = (pluginName: string): string => {
+const tryResolvePackage = (packageName: string): boolean => {
+  try {
+    import.meta.resolve(packageName);


Only concern is whether it can actually resolve this, e.g. if you use npx @oxlint/migrate but your project is using yarn or pnpm, will npx be able to resolve the packages?

connorshea · 2026-02-23T04:03:07Z

Alright, I think this correctly handles all three cases:

@e18e/eslint-plugin but with e18e meta.name means that the rules should be e18e/rule-name.
@tanstack/eslint-plugin-query can be used with rule names like @tanstack/query/rule-name.
@eslint-react/eslint-plugin with sub-plugins is handled correctly, migrates such that we rename the rules to use the canonical scopes (react-dom/no-flush-sync for the rule, eslint-plugin-react-dom for the plugin), as Oxlint doesn't handle the aliasing right now without using the specifier system in the Oxlint config itself.

I guess we could consider setting this up to explicitly use the aliasing system for the last edge case. Then the rules can have names like @eslint-react/dom/rule-name? But I'd rather do that in a separate PR if we want to do it, as I have confirmed that this current PR works correctly as-is, and it fixes a user's active problem.

Sysix · 2026-02-23T17:54:49Z

src/plugins_rules.ts

+          // with enabled rules that go through enableJsPluginRule.
+          const resolvedRule = resolveJsPluginRuleName(
+            rule,
+            eslintConfig.plugins


Can a rule be activated from a plugin declaration from another ESLint config?
Something like:

export default [ {"plugins": await import("xyz") }, {"rules": { "xyz/rule-1": "error" } } ]

hmm, I'm not sure if you can do it async like that, but it can be activated from another config

The async part was only for code demo :).
Then we should probably collect first all plugins across every ESLint config?

Hmm, after thinking on it more: I think the plugins value should be fully resolved at this point in our evaluation of the config. So I'm pretty sure this wouldn't be a problem?

Not 100% sure, somebody needs to test it :')
The first call will have only {"plugins": ...} and the second call will only have the rule {"rules": {"xyz-rule1": ...}}.

resolveJsPluginRuleName does not access the global resolved plugin cache. Instead, it relies on eslintConfig.plugins

I've added a snapshot test and confirmed the behavior of ESLint is as you described, now I just need to fix it...

Fixed :) e044a9d

Ah you mentioned "across all plugins". I didn't realize this case would work as well, let me make sure this case is fixed 🙃

import e18e from '@e18e/eslint-plugin'; export default [ { rules: { 'e18e/prefer-array-at': 'error', 'e18e/prefer-includes': 'warn' }, }, { plugins: { e18e } }, ];

^ FWIW I did test that just now (with @eslint-react/dom/ as well) and it worked correctly with no code changes, so we're good!

This is just taking some of the tests added in #402 and porting them to main so I can avoid merge conflicts later. I assume these tests are safe to merge since they are just tests and are simple enough.

Instead of guessing the npm package name from the plugin scope (e.g. "e18e" → "eslint-plugin-e18e"), try to resolve the actual installed package. This correctly handles plugins like @e18e/eslint-plugin that register with a non-scoped name ("e18e") but whose npm package uses the @scope/eslint-plugin convention. For non-scoped plugin names, we now try both candidate conventions: 1. eslint-plugin-{name} (standard, e.g. eslint-plugin-mocha) 2. @{name}/eslint-plugin (scoped, e.g. @e18e/eslint-plugin) Results are cached to avoid repeated module resolution. https://claude.ai/code/session_01GBWbJpvKSgVenUQNzc27dg

When an ESLint plugin provides meta.name, use it as the authoritative source for the npm package name rather than guessing from the rule ID. If meta.name contains "eslint-plugin" it is used directly; otherwise it is fed through the existing heuristic resolution. https://claude.ai/code/session_01GBWbJpvKSgVenUQNzc27dg

This PR fixes oxc-project#377.

When a plugin is registered under an alias (e.g. `@eslint-react/dom`) but its `meta.name` reveals a different canonical package name (e.g. `eslint-plugin-react-dom`), rewrite rule prefixes so oxlint can match them to the loaded plugin. For example: @eslint-react/dom/no-find-dom-node -> react-dom/no-find-dom-node @eslint-react/jsx-key-before-spread -> react-x/jsx-key-before-spread https://claude.ai/code/session_01GBWbJpvKSgVenUQNzc27dg

connorshea · 2026-02-27T02:05:16Z

I have merged the integration tests for the @tanstack and e18e plugins into main via a separate PR to make this one easier to understand and review :)

Sysix · 2026-02-27T13:20:34Z

src/plugins_rules.ts

+          // with enabled rules that go through enableJsPluginRule.
+          const resolvedRule = resolveJsPluginRuleName(
+            rule,
+            eslintConfig.plugins


Not 100% sure, somebody needs to test it :')
The first call will have only {"plugins": ...} and the second call will only have the rule {"rules": {"xyz-rule1": ...}}.

resolveJsPluginRuleName does not access the global resolved plugin cache. Instead, it relies on eslintConfig.plugins

Sysix · 2026-02-27T13:20:37Z

src/jsPlugins.ts

+    return rule;
+  }
+
+  const metaName = plugins?.[pluginName]?.meta?.name;


This adds a snapshot test to ensure that the, I confirmed in a test repo that this is valid and works in ESLint. We need to fix the logic of oxlint-migrate to handle it.

It does not result in the correct config right now.

Sysix · 2026-03-01T18:49:23Z

thank you for looking into this and confirming the global plugins problem :)

connorshea changed the title ~~test: Add e18e ESLint plugin integration test~~ fix: Fix plugin scope determination logic, and add e18e ESLint plugin integration test Feb 23, 2026

connorshea commented Feb 23, 2026

View reviewed changes

connorshea mentioned this pull request Feb 23, 2026

Add integration tests for eslint-react and react-web-api #403

Merged

connorshea force-pushed the claude/add-oxlint-migrate-snapshot-test-7b5QK branch from 7bbd47d to 5a9a01c Compare February 23, 2026 02:20

connorshea mentioned this pull request Feb 23, 2026

Incorrect migration of js plugin @eslint-react/eslint-plugin #377

Closed

connorshea commented Feb 23, 2026

View reviewed changes

connorshea requested a review from Sysix February 23, 2026 02:24

This comment was marked as outdated.

Sign in to view

connorshea mentioned this pull request Feb 23, 2026

Linter plugins: Support plugins with / in name oxc-project/oxc#14557

Open

connorshea force-pushed the claude/add-oxlint-migrate-snapshot-test-7b5QK branch from ec5d2f7 to 982ccdc Compare February 23, 2026 03:52

connorshea requested a review from overlookmotel February 23, 2026 03:57

Sysix reviewed Feb 23, 2026

View reviewed changes

connorshea mentioned this pull request Feb 27, 2026

test: Add e18e and tanstack eslint plugins to integration tests. #407

Merged

connorshea force-pushed the claude/add-oxlint-migrate-snapshot-test-7b5QK branch from 982ccdc to c9db8fc Compare February 27, 2026 02:00

claude and others added 5 commits February 26, 2026 19:01

fmt.

8f29937

Update eslint react snapshot.

0f31848

This PR fixes oxc-project#377.

connorshea force-pushed the claude/add-oxlint-migrate-snapshot-test-7b5QK branch from c9db8fc to 6c49337 Compare February 27, 2026 02:03

connorshea changed the title ~~fix: Fix plugin scope determination logic, and add e18e ESLint plugin integration test~~ fix: Fix plugin scope determination logic Feb 27, 2026

connorshea requested a review from Sysix February 27, 2026 02:05

Sysix reviewed Feb 27, 2026

View reviewed changes

connorshea added 3 commits March 1, 2026 11:07

Add test for cross-config plugin scenario with ESLint flat config.

1020177

This adds a snapshot test to ensure that the, I confirmed in a test repo that this is valid and works in ESLint. We need to fix the logic of oxlint-migrate to handle it.

Add an aliased config for testing purposes.

95cd616

It does not result in the correct config right now.

Fix the bug with cross-config aliases.

e044a9d

connorshea requested a review from Sysix March 1, 2026 18:35

Sysix approved these changes Mar 1, 2026

View reviewed changes

Sysix merged commit 69a3821 into oxc-project:main Mar 1, 2026
2 checks passed

This was referenced Mar 10, 2026

fix: keep jsPlugins entry for off rules in overrides #429

Merged

feat: convert unsupported ESLint rules to JS plugins #393

Draft

Uh oh!

Conversation

connorshea commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as outdated.

connorshea commented Feb 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sysix Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

connorshea commented Feb 27, 2026

Uh oh!

Sysix Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sysix commented Mar 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

connorshea commented Feb 23, 2026 •

edited

Loading

Sysix Feb 27, 2026 •

edited

Loading

Sysix Feb 27, 2026 •

edited

Loading