linter: JavaScript plugin code path listeners missing node parameter

[C5G6M7]

What version of Oxlint are you using?

1.41.0

What command did you run?

npx oxlint --config oxlint.json

What does your .oxlintrc.json config file look like?

{
  "$schema": "./node_modules/oxlint/configuration_schema.json",
  "jsPlugins": [
    "./plugins/sonarjs-plugin.js"
  ],
  "rules": {
    "sonarjs/super-invocation": "error",
    "sonarjs/no-parameter-reassignment": "error",
    "sonarjs/no-invariant-returns": "error",
    "sonarjs/no-inconsistent-returns": "error",
    "sonarjs/no-code-after-done": "error",
    "sonarjs/no-redundant-assignments": "error",
    "sonarjs/no-dead-store": "error"
  }
}

What happened?

Oxlint's JavaScript plugin API is documented to be fully compatible with ESLint v9+, including code path analysis. However, when using eslint-plugin-sonarjs via the JavaScript plugin API, code path listeners are sometimes called without the node parameter, or with null/undefined code path objects, causing errors.

Affected Rules

The following 7 rules from eslint-plugin-sonarjs are affected:

1. super-invocation
2. no-parameter-reassignment
3. no-invariant-returns
4. no-inconsistent-returns
5. no-code-after-done
6. no-redundant-assignments
7. no-dead-store

Issue Types

1. Missing Node Parameter in Code Path Listeners

Problem: Oxlint sometimes calls code path listeners without the node parameter that ESLint provides.

Expected behavior (per ESLint API):

onCodePathStart(codePath, node)  // node should always be provided
onCodePathEnd(codePath, node)
onCodePathSegmentStart(segment, node)
onCodePathSegmentEnd(segment, node)
onCodePathSegmentLoop(fromSegment, toSegment, node)

Actual behavior: These listeners are sometimes called with node as undefined or null.

Impact: Rules that expect a node parameter to call context.getScope(node) will fail with errors like:

• TypeError: Missing required argument: 'node'
• Cannot read properties of undefined (reading 'type')

2. Null/Undefined Property Access Errors

Problem: Code path objects or nodes may be null/undefined when accessed by rule listeners.

Examples of errors observed:

• Cannot read properties of null (reading 'isConstructor') - in CallExpression:exit and ReturnStatement listeners
• Cannot read properties of null (reading 'hasExtends') - in onCodePathEnd listener
• Cannot read properties of null (reading 'currentSegments') - in onUnreachableCodePathSegmentStart/End listeners
• Cannot read properties of undefined (reading 'type') - in onCodePathStart listener

Impact: Rules that access properties on code path objects or nodes will throw errors instead of completing analysis.

3. Code Path Stack Not Initialized

Problem: Some rules access context.codePathStack or similar structures that may not be properly initialized in Oxlint.

Impact: Rules that rely on code path stack tracking will fail.

Current Workaround

We've implemented a workaround in our plugin wrapper that patches the affected rules to:

• Skip execution when node parameters are missing
• Catch and handle null/undefined property access errors
• Gracefully handle code path stack access errors

However, this workaround prevents crashes but may result in incomplete rule analysis for these rules.

Expected Behavior

According to the Oxlint JavaScript Plugin API documentation, the API should be "fully compatible with ESLint v9+", and code path listeners should receive both codePath and node parameters consistently, matching ESLint's behavior.

Minimal Reproduction

The issue can be reproduced directly with eslint-plugin-sonarjs (a JavaScript package, not TypeScript):

1. Install eslint-plugin-sonarjs: npm install eslint-plugin-sonarjs
2. Configure oxlint to use the plugin and enable any of the 7 affected rules
3. Run oxlint on code that triggers code path analysis

The errors occur during normal linting when these rules attempt to analyze code paths.

Additional Context

• Documentation reference: ESLint Code Path Analysis
• Affected plugin: SonarJS Plugin
• This appears to be a compatibility gap in Oxlint's JavaScript plugin API implementation, not an issue with the ESLint plugin itself
• Note on API compatibility: While ESLint flat config requires meta.name for certain features (like --cache and --print-config), some plugins may still function without it. Oxlint appears to strictly require meta.name for all plugins, which is a minor API drift from ESLint's more lenient approach. However, eslint-plugin-sonarjs already provides meta.name, so this is not a factor in this particular issue.

[overlookmotel]

Thanks for raising this. Strange! Will look into it.

Oxlint appears to strictly require meta.name for all plugins

That shouldn't be the case, and I didn't think it was. meta.name is not required if the plugin is loaded with a package specifier (e.g. "jsPlugins": ["eslint-plugin-sonarjs"]). It's only required if the plugin is loaded with a relative path (e.g. "jsPlugins": ["../../path/to/plugin.js"]). It's required in the latter case, because there's nowhere else for the plugin name to come from.

Have you found otherwise?

[C5G6M7]

Hey thanks for the quick response on this.

I tested the meta.name requirement with oxlint 1.42.0. Here are the results:

Oxlint requires meta.name, but it can be satisfied in three ways:

1. Define meta.name in the plugin object (ESLint-compatible):

   const plugin = {
     meta: { name: "plugin-name" },
     rules: { ... }
   };

2. Provide an alias in the jsPlugins config:

   {
     "jsPlugins": [
       { "name": "plugin-name", "specifier": "./plugin.js" }
     ]
   }

3. Load from an NPM package with a name field in package.json

Test results:

• Plugin without meta.name and no alias: FAILED with error: "Plugin must either define meta.name, be loaded from an NPM package with a name field in package.json, or be given an alias in config"
• Plugin with meta.name: SUCCESS
• Plugin without meta.name but with alias: SUCCESS

This differs from ESLint, which doesn't require meta.name (though it's recommended). In our case, eslint-plugin-sonarjs already provides meta.name, so this isn't affecting the code path listener issue.

The main issue remains the missing node parameter in code path listeners, which is separate from the meta.name requirement.

[overlookmotel]

Do you have a reproduction for this please?

Plugin without meta.name and no alias: FAILED with error: "Plugin must either define meta.name, be loaded from an NPM package with a name field in package.json, or be given an alias in config"

We have a test for exactly this case, and it passes.

https://github.com/oxc-project/oxc/tree/1363943f3db3075e9e3b049386fc25d29d4198ae/apps/oxlint/test/fixtures/plugin_name

See the plugin plugin2 in node_modules/plugin2. It has no meta.name defined in the plugin object, and the config does not provide an alias for it either. And it works - the plugin's name in Oxlint is "plugin2-name-from-package", which comes from the package.json in node_modules/plugin2.

---

I'm looking into the main issue about code path listeners.

[overlookmotel]

I'm having difficulty replicating your findings. Can't find a case where code path listeners are called with the wrong parameters.

Can you possibly provide a self-contained reproduction - A specific SonarJS rule and a file to run it on where the rule doesn't do what it should?

Note: The rules which rely on type info from TS-ESLint won't work in Oxlint, because we can't provide type information. TSGo doesn't currently expose that info in a way that we could use it. I don't know if the 7 rules you mention fall into that category or not, but nonetheless the code path listeners should still behave as they should - the problem will be that sourceCode.parserServices has no properties.

[C5G6M7]

Yes, I will put a reproduction together and get back to you.

[overlookmotel]

I've figured it out!

I added eslint-plugin-sonarjs to our conformance testing. This runs all the plugin's tests with all the rules running as Oxlint JS plugins. Many of the rules use code path analysis, and it didn't show any sign of malfunctions of the kind you've described.

But I just realized that the problem isn't in the code path analysis itself. It's in the mechanism that merges multiple visitors into 1 before running the visitor over the AST. That was built before we added code path support so it assumes all visitor functions take only a single argument. That's true for "normal" AST visitors (only take node), but it's not true for the code path listeners. So it only passes through the 1st argument to the merged listener functions.

This bug didn't show up in the conformance tests because that runs each rule in isolation. Listeners are only combined when more than 1 rule uses the same listener.

Thanks for uncovering this. Am working on a fix now.

[C5G6M7]

I'm glad to help and I apologize for not getting back sooner. I'm up against a client deadline.

Just in case this is still helpful, attached is a minimal repo that produces both issues

oxlint-sonarjs-repro-issue-18555.zip