linter: add filtering to the rules list

[Sheraff]

Now that the number of rules has grown so large, it would be nice to add some filtering so that users have an easier time finding what they are looking for:

• for example, typescript-eslint makes their "emoji legend" clickable to filter in / out some categories. This is pretty useful if, for example, you only want to see the fixable rules
  

• for example, eslint indicates when a rule is made redundant by the use of typescript, which is useful to know when wanting to avoid double reporting of issues in CI and to make the errors easier to understand in IDEs (idk why this is not more prominent on eslint's website)
  

• in addition, oxc has rules inspired by many existing eslint plugins (unicorn, jsx-a11y, ...) which could also be used as a target for filtering. This would be useful for folks familiar with these plugins

---

References:

• typescript-eslint list of rules, filtered, w/ filters reflected in the URL https://typescript-eslint.io/rules/?=recommended-xtypeInformation#rules
• eslint no-const-assign rule, w/ a paragraph about redundancy w/ typescript https://eslint.org/docs/latest/rules/no-const-assign

[therewillbecode]

Just curious, how is the issue of double-reporting with eslint and eslint-typescript normally handled by the community? Do users typically disable overlapping rules on a case by case basis individually? I am wondering if there is a generally agreed upon strategy for which rules to disable?

Maybe some example configs for dealing with the overlapping rules could be made available somewhere so users aren't forced to go through the website UI filters to curate the rules config to avoid this common problem unless they want to.

[Sheraff]

That's a very good question. It looks like no-const-assign is a good example of the issue:

• it's enabled by default in eslint/js/recommended
• and disabled by typescript-eslint/recommended
  • disabled in typescript-eslint/eslint-recommended-raw: https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/src/configs/eslint-recommended-raw.ts
  • which is applied when using typescript-eslint/eslint-recommended: https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/typescript-eslint/src/configs/eslint-recommended.ts
  • which itself is applied when using typescript-eslint/recommended: https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/typescript-eslint/src/configs/recommended.ts

It looks like we can actually get the full list of "covered by TS" from that first link:

    'constructor-super': 'off', // ts(2335) & ts(2377)
    'getter-return': 'off', // ts(2378)
    'no-class-assign': 'off', // ts(2629)
    'no-const-assign': 'off', // ts(2588)
    'no-dupe-args': 'off', // ts(2300)
    'no-dupe-class-members': 'off', // ts(2393) & ts(2300)
    'no-dupe-keys': 'off', // ts(1117)
    'no-func-assign': 'off', // ts(2630)
    'no-import-assign': 'off', // ts(2632) & ts(2540)
    // TODO - remove this once we no longer support ESLint v8
    'no-new-symbol': 'off', // ts(7009)
    'no-new-native-nonconstructor': 'off', // ts(7009)
    'no-obj-calls': 'off', // ts(2349)
    'no-redeclare': 'off', // ts(2451)
    'no-setter-return': 'off', // ts(2408)
    'no-this-before-super': 'off', // ts(2376) & ts(17009)
    'no-undef': 'off', // ts(2304) & ts(2552)
    'no-unreachable': 'off', // ts(7027)
    'no-unsafe-negation': 'off', // ts(2365) & ts(2322) & ts(2358)
    'no-var': 'error', // ts transpiles let/const to var, so no need for vars any more
    'prefer-const': 'error', // ts provides better types with const
    'prefer-rest-params': 'error', // ts provides better types with rest args over arguments
    'prefer-spread': 'error', // ts transpiles spread to apply, so no need for manual apply

[shulaoda]

What do you think? Should we try to support it? @Boshen