[eslint-plugin] Breaking: enable type information for prefer-optional-chain

[JoshuaKGoldberg]

Overview

Following #4706 (comment): neither rule @typescript-eslint/prefer-optional-chain does not require type information right now but would be able to avoid many false positives with it. Both @bradzacher and I have felt that pain repeatedly.

For the 6.0 release, it'd be great have type information added as a breaking change! That would enable adding the rules rule to recommended-requiring-type-checking stylistic-type-checked.

[JoshuaKGoldberg]

Oh: @typescript-eslint/prefer-nullish-coalescing already requires type checking! So this is just for @typescript-eslint/prefer-optional-chain.

[JoshuaKGoldberg]

Fixed by #6397

[eltonio450]

Hi there,

We just updated to 6.0.0

the problem is that we have a dual config:

• no type checking, running on commit hook and developers IDE
• type checking, running in the CI, because we have a large monorepo

For rules that have migrate from non type checked to type-checked (such as prefer-optional-chain), we lost instant feedback (and autofix) in the IDE by upgrading to v6

do you have any guidance here ? Would it be possible to have, for some of those rules, two version of the rules, one with typechecking enabled, one without ?

thank you

[jakebailey]

You should be able to just check if the program is present: https://github.com/microsoft/TypeScript/pull/54693/files#diff-df5c64397795f7703783a51bb8f0d646e9594f68a57891b334875b1003f48982L183

[bradzacher]

Would it be possible to have, for some of those rules, two version of the rules, one with typechecking enabled, one without ?

Short answer - no.

When we add type information to a rule we do so very carefully and very intentionally because we know that it restricts many users from being able to use a rule. When we do it we must have a very good reason.

This is triply true when it comes to an existing rule because people that used to use the rule can no longer use it.

In this instance the type information was added because there were numerous bugs with the rule. These were bugs that could cause the rule to autofix break your build by changing types. Bugs that could introduce optional chaining where one wasn't valid and change the meaning of your code.

The only way to fix these bugs was to introduce type information into the rule so that it could accurately identify these cases.

Our published rules cannot have such egregious bugs in them - but private rules can act however you wish. If you felt like the bugs were acceptable for you - our code is intentionally permissively licenced so you're free to fork the rule locally and remove the type info if you wish. Though we of course would not advise doing this for obvious reasons!

[eltonio450]

very clear, thank you for the explanation and pinning the code should we decide to rollback to the old version of the rule :)

I agree that it makes sense to be very cautious with this rule, we learnt it the hard way!

Thank you very much!