linter: Consider policy on moving a lint rule back into nursery if significant problems are discovered post-release

[connorshea]

For example, the import/extensions rule has a few known issues which have taken a while to get fixes created/merged for:

• linter: eslint-plugin-import(extensions) false positives with missing extension #12220
• linter: false positive for module with import/extensions rule #11881
• linter: import/extensions rule should have mjs/mts/cjs/cts options #15509

(This is in no way intended as criticism or to cast blame on anyone, and is just an example I had for the purposes of the proposal)

I think we should consider a policy for whether rules should be/can be moved into the nursery category in cases like this, where fixes to issue(s) with the rule cannot easily/quickly be implemented, and a rule has already been shipped as a non-nursery rule.

It would hopefully not need to happen too often, and should generally be reserved for serious issues/differences from the original rules, but it would be valuable in ensuring that users will be able to make more informed decisions when migrating for cases like this, until we can ship fixes for significant issues in a rule.

Maybe something like "After X weeks without a fix, if an issue (particularly an unintended divergence from the original ESLint rule) is considered severe enough, a rule can be moved into the nursery to avoid users running into problems".

I realize this would mean we'd be by-default disabling a rule for users when they upgrade, and so would potentially be considered a breaking change, but I think it's worth considering.

[tt-a1i]

I think this is a reasonable policy to consider. Having recently worked on implementing the no-sequences rule, I've noticed that ESLint compatibility can be tricky - there are subtle edge cases (like grammar-required parentheses vs user-added parentheses, or arrow function body handling) that are easy to miss initially.

A few thoughts:

1. Proactive approach: Rather than waiting for issues to accumulate, we could strengthen the pre-release testing process. For example, running the rule against popular open-source projects and comparing output with ESLint could catch divergences early.

2. Graduated response: Maybe before moving a rule back to nursery, there could be an intermediate step - like adding a warning in the docs or release notes about known issues, giving maintainers time to address them.

3. Clear criteria: If we do adopt a nursery-rollback policy, having explicit criteria would help (e.g., "false positives affecting >X% of common patterns" or "behavior divergence from ESLint in documented examples").

That said, I agree that user trust is important - shipping a rule that causes significant noise undermines confidence in oxlint as an ESLint replacement.