tsserver: deprecate getSupportedCodeFixes, add fixable property to Diagnostic

[ajafff]

This proposes an alternative to #29010. Making getSupportedCodeFixes proxy-able by plugins means the client has to request the list of fixable error codes for each file - and theoretically everytime the program is updated (because the configuration of a plugin could have changed).

Could we instead just add a new property fixable to Diagnostic?
That makes getSupportedCodeFixes obsolete. Fixable error codes no longer need to be known in advance, which would also resolve #28990.

[sheetalkamat]

Adding @mjbvz @amcasey @DanielRosenwasser for their thoughts on this.

[mjbvz]

I don't see any problem supporting this in VS Code. We'll still have to support getSupportedCodeFixes for older TS versions though

[amcasey]

I assume that request exists because VS requires it to implement a Roslyn API. (Of course, there may be cheaper ways to implement the same API.)

[DanielRosenwasser]

I guess the problem with this approach is that it couples the compiler pretty closely with the capabilities of the language service. Why is the compiler's responsibility to know ahead of time that something will be fixable? It feels a little funky from that perspective.

[ajafff]

@DanielRosenwasser this proposal doesn't change the compiler at all. LanguageService.get*Diagnostics would request the diagnostics from the compiler and augment them with the fixable property which is looked up in errorCodeToFixes in codeFixProvider.ts (this is also what powers getSupportedCodeFixes).

[ajafff]

It there a chance this proposal or #28966 will be accepted? I'm currently working on my language service plugin again and it bugs me out, that I have to trade clear error names for numeric codes just to be able to provide code fixes.