Self-lint SonarJS's own ESLint rules with eslint-plugin-eslint-plugin (recommended)

Suggest new features
1

eslint-plugin-sonarjs is an ESLint plugin, but its own eslint config doesn’t appear to lint the plugin’s rule files with eslint-plugin-eslint-plugin.

Concretely, its recommended config catches things that are easy to miss by hand and that silently break for end users:

  • no-deprecated-context-methods / no-deprecated-report-api (autofixable) — flags calls like context.getSourceCode() or the old multi-arg context.report(node, message). ESLint has been removing these across major versions, so a rule using them keeps working until a user upgrades ESLint and the rule crashes at runtime with no warning beforehand.
  • fixer-return — catches a fixer function with a code path that doesn’t return a fix, i.e. a silently broken --fix.
  • no-missing-placeholders / no-unused-placeholders — catches a mismatch between {{placeholder}} tokens in a report message and the data actually passed, i.e. a broken or garbled error message shown to users.
  • require-meta-schema / require-meta-type / require-meta-fixable — catches rules missing meta fields that editors, eslint --init, and the ESLint config inspector rely on to show correct docs and fixability.
  • no-identical-tests / prefer-output-null — catches copy-pasted or no-op cases in the rule’s own test suite that aren’t actually asserting anything.

None of this needs manual review — it’s exactly what a linter is good at, pointed at the plugin’s own source.

Suggestion: add it as a devDependency and apply its recommended config to the rules directory:

import eslintPlugin from 'eslint-plugin-eslint-plugin';

export default [
  // ...existing config
  {
    ...eslintPlugin.configs.recommended,
    files: ['**/rules/**/*.js'], // adjust to your rules path
  },
];

(For context, this exact recommended setup is already running in eslint-stylistic, eslint-plugin-import-x, eslint-plugin-perfectionist, eslint-plugin-unicorn, eslint-plugin-jsx-a11y-x, and facebook/react’s own eslint-plugin-react-hooks — so it’s a well-trodden config, not a novel ask.)

Happy to open a PR if this is a welcome change.

4

Hi Pavel,

Thanks for the suggestion and the detailed explanation! This looks like a useful addition to SonarJS’s checks. We’ve created JS-2587 to track it.

We’ll need to account for our generated rule metadata and custom test helpers, but the approach makes sense.

Thanks again for bringing this to our attention.