[Feature Request] Support codeAction/resolve

[Brady Madden]

In newer versions of the LSP spec, clients and servers can support not sending certain fields with textDocument/codeActions requests, and instead resolving those fields for a specific code action through a subsequent codeAction/resolve request:

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_codeAction

This can be beneficial for situations where fields (like the edit field in a code action) is computationally expensive to calculate. The language server can defer calculating those fields for the initial textDocument/codeActions request that returns many code actions. Then, when a user chooses a code action, the client can make a request just for that code action to codeAction/resolve, retrieve the edit information, and apply the workspace edit. It trades potential additional latency on every single textDocument/codeActions request for slightly more latency when executing a single code action.

I tried to make a codeAction/resolve request to typescript-language-server and found that it was not supported.

My request is

• Support codeAction/resolve
• Respect the associated capabilities (resolveSupport on the client and resolveProvider from the server)

[Rafał Chłodnicki]

This server relies on typescript (tsserver) API to get the data. Since the only API that it provides is one that returns code actions with all the needed data, it wouldn't make sense to not return that data in the initial textDocument/codeAction response already.

Do you see any actual issues with the current approach? I have never thought to myself: "this code action request is slow, I wish it would be faster...".