linter: fix codebase for same rule in different plugin/scopes

[Sysix]

Background

In the eslint world there are similiar rule (names) in different plugins. As an example:

• no-unused-vars and @typescript-eslint/no-unused-vars
• vitest/no-identical-title and jest/no-identical-title

Problems

Because oxlint support them only in one scope (vitest in jest and @typescript-eslint in eslint),
there are some problems.

Documentation

• fix(docs): detect typescript alias rules and mark them as supported #3779 (and some follow up)
• fix(tasks/lint_rules): sync vitest compatible rules with jest rules #6667

Implementation with config

• linter: no matching rules for some typescript rules #7233
• linter: jest and vitest compatible rules are reported as not supported #7240

Integration with eslint-plugin-oxlint

in this project we need to keep track for the configs and the new method buildFromOxlintConfigFile

• sync vitest compatible rules with jest rules eslint-plugin-oxlint#187
• fix: mark typescript rules, which extend eslint rule, as supported eslint-plugin-oxlint#165

Discussion

I want to have a simple way to parse the rules for all specific use cases.
In discord there is also a import/no-namespace upcoming rule wich conflicts with @typescript-eslint,
see here https://discord.com/channels/1079625926024900739/1080712072012238858/1304749400383291422
This problem crops up more often, the more plugins we are supporting.

[nrayburn-tech]

I agree that this is an issue and I would like to see it addressed somehow. As you mention, the more plugins that are supported the more often this is an issue. I expect it will continue to get worse, especially when custom plugins become available.

[Boshen]

It was an oversight to not allow identical names, let's treat it as a bug and fix accordingly.

[pumano]

Would love if it will be fixed, because typescript/no-namespace and import/no-namespace can be used too without changing name

[pumano]

Looks like #7082 related to that problem too.

@Sysix @nrayburn-tech how we can fix it?

[pumano]

@camchenry @camc314 could you help us with that solution or guide us, how we can do it?

[camc314]

thoughts on the following:
when using the cli, rules can either be enabled with their name
e.g no-non-null-assertions
OR their scoped name @ typescript/no-non-null-assertions

?

will try to look at this tomorrow

[pumano]

@camc314 any news on this? Looks like we need to fix naming problem.

Maybe add forced scope to all rules with exception to eslint rules?

If we implement it, we got proper working for rules below, without naming collisions:

"no-unused-vars": "error", // or off
"@typescript-eslint/no-unused-vars": "error", 
"@typescript-eslint/no-namespace": "error",
"import/no-namespace": "error",
"vitest/no-identical-title": "error", 
"jest/no-identical-title": "error"

[camc314]

afraid not. there's been a lack of time.

[camc314]

#7496

[Sysix]

@camc314 & @Boshen what are the next plans to support rules, which extends some other rules?

See linked issues + a new found: oxc-project/eslint-plugin-oxlint#263

I tried to collect all known rules for oxc project:

Rules which are implemented in eslint and extended in @typescript-eslint:

Note: This are ALL rules, we do not support all of them because some are cosmetic and should be implemented in oxc_prettier

• 'block-spacing'
• 'brace-style'
• 'class-methods-use-this'
• 'comma-dangle'
• 'comma-spacing'
• 'default-param-last'
• 'func-call-spacing'
• 'indent'
• 'init-declarations'
• 'key-spacing'
• 'keyword-spacing'
• 'lines-around-comment'
• 'lines-between-class-members'
• 'max-params'
• 'no-array-constructor'
• 'no-dupe-class-members'
• 'no-empty-function'
• 'no-extra-parens'
• 'no-extra-semi'
• 'no-invalid-this'
• 'no-loop-func'
• 'no-loss-of-precision'
• 'no-magic-numbers'
• 'no-redeclare'
• 'no-restricted-imports'
• 'no-shadow'
• 'no-unused-expressions'
• 'no-unused-vars'
• 'no-use-before-define'
• 'no-useless-constructor'
• 'object-curly-spacing'
• 'padding-line-between-statements'
• 'quotes'
• 'semi'
• 'space-before-blocks'
• 'space-before-function-paren'
• 'space-infix-ops'

Rules which are implemented in jest but also supported for vitest:

Note: This CAN BE all supported rules by oxc
I do not know if they extend are just in another plugin

• 'consistent-test-it'
• 'expect-expect'
• 'no-alias-methods'
• 'no-conditional-expect'
• 'no-conditional-in-test'
• 'no-commented-out-tests'
• 'no-disabled-tests'
• 'no-focused-tests'
• 'no-identical-title'
• 'no-restricted-jest-methods'
• 'no-test-prefixes'
• 'prefer-hooks-in-order'
• 'valid-describe-callback'
• 'valid-expect'

Rules which are implemented in eslint and and extended in unicorn:

Note: This are FOUND rules supported by oxc

• prefer-spread

[Boshen]

I think we should mark them as implemented in both eslint plugins.

If things start getting annoying, we may need to add some meta data to these rules.

For oxlint plugin, we may want to add an API in oxlint to get the number of rules with full metadata instead of parsing rules.rs (correct me if I am wrong).

[Sysix]

the eslint plugin eslint-plugin-oxlint does not parse the rules.rs.
Instead it looks recursivly into the rules directory and getting all informations (category: correctness, style, .., plugin-name: folder)

I am already getting annoyed because of the 3 big parts:

• Documentation in oxlint
• Detection in oxlintrc.json (maybe even oxlint cli, did not test it)
• Remapping in eslint-plugin-oxlint

[Sysix]

Closing in favour of #7622, #7574 and #7567

the rest should be eslint-plugin-oxlint problems and can be fixed in the own repo

[Sysix]

@camc314 Sorry to bother you, I did not want to spam in this PR #8149 (comment)

The starting discoussion will apply to the PR too. We need to sync the docs and the matching inside eslint-plugin-oxlint.
I still want a better solution <3

[camc314]

no worries.

do you have an example of where the docs are incorrect?
i'm not familiar with eslint-plugin-oxlint, mind pointing me to how it uses it?

or what changes you need to get it working?

[Sysix]

we needed to implement the sync for the docs in:

#3779
#6667

Now with #8149 we need to do the same.

For the eslint-plugin-oxlint problem:
I already created an PR to use the new format in #7574, you can see here:
oxc-project/eslint-plugin-oxlint#287

I still need to remap the rules here:
https://github.com/oxc-project/eslint-plugin-oxlint/blob/build-use-oxlint-rules-command/scripts/traverse-rules.ts#L60-L79

and for the ingration tests with oxlint:
https://github.com/oxc-project/eslint-plugin-oxlint/blob/build-use-oxlint-rules-command/src/build-from-oxlint-config.spec.ts#L419-L433