Open ajafff opened 5 years ago
Adding @mjbvz @amcasey @DanielRosenwasser for their thoughts on this.
I don't see any problem supporting this in VS Code. We'll still have to support getSupportedCodeFixes
for older TS versions though
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.)
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.
@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
).
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.
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
toDiagnostic
? That makesgetSupportedCodeFixes
obsolete. Fixable error codes no longer need to be known in advance, which would also resolve #28990.