这提出了一个替代 #29010 的方法。使 getSupportedCodeFixes 通过插件代理意味着客户端需要为每个文件请求可修复的错误代码列表，理论上每次程序更新时都需要这样做(因为插件的配置可能会发生变化)。我们是否可以仅仅添加一个新的属性 fixable 到 Diagnostic 呢？这样就使得 getSupportedCodeFixes 过时了。不再需要提前了解可修复的错误代码，这也将解决 #28990 的问题。
getSupportedCodeFixes
fixable
Diagnostic
xmjla07d1#
这个提案或#28966有被接受的可能性吗？我目前正在重新编写我的语言服务插件，这让我很烦恼，因为我不得不用清晰的错误名称换取数字代码，才能提供代码修复。
disho6za2#
@DanielRosenwasser 这个提案并不会改变编译器。LanguageService.get*Diagnostics 会从编译器请求诊断信息，并用fixable属性增强它们，该属性在errorCodeToFixes中查找(这也是getSupportedCodeFixes的动力所在)。
LanguageService.get*Diagnostics
errorCodeToFixes
hfsqlsce3#
我假设这个请求是存在的，因为VS需要它来实现Roslyn API。(当然，可能有更便宜的方法来实现相同的API。)
pcww981p4#
我认为这种方法的问题在于它将编译器与语言服务的能力紧密耦合在一起。为什么编译器的职责是提前知道某些东西是可以修复的？从这个Angular 来看，这感觉有点奇怪。
vlju58qv5#
我不认为在VS Code中支持这个有任何问题。尽管如此，我们仍然需要为旧版本的TS提供支持。
r1zk6ea16#
@mjbvz@amcasey@DanielRosenwasser 对此提出了他们的想法。
6条答案
按热度按时间xmjla07d1#
这个提案或#28966有被接受的可能性吗？我目前正在重新编写我的语言服务插件，这让我很烦恼，因为我不得不用清晰的错误名称换取数字代码，才能提供代码修复。
disho6za2#
@DanielRosenwasser 这个提案并不会改变编译器。
LanguageService.get*Diagnostics会从编译器请求诊断信息，并用fixable属性增强它们，该属性在errorCodeToFixes中查找(这也是getSupportedCodeFixes的动力所在)。hfsqlsce3#
我假设这个请求是存在的，因为VS需要它来实现Roslyn API。(当然，可能有更便宜的方法来实现相同的API。)
pcww981p4#
我认为这种方法的问题在于它将编译器与语言服务的能力紧密耦合在一起。为什么编译器的职责是提前知道某些东西是可以修复的？从这个Angular 来看，这感觉有点奇怪。
vlju58qv5#
我不认为在VS Code中支持这个有任何问题。尽管如此，我们仍然需要为旧版本的TS提供支持。
r1zk6ea16#
@mjbvz@amcasey@DanielRosenwasser 对此提出了他们的想法。