LSP textDocument/completion request: CompletionItem.detail should be not null unless the editor reports the corresponding capability

[alexander-doroshko]

Hi from JetBrains!

We are using the Tailwind CSS LSP server (@tailwindcss/language-server) for the Tailwind CSS support in JetBrains IDEs.

I noticed that on the textDocument/completion request, the LSP server initially returns completion items with CompletionItem.detail == null. The editor needs to send an additional completionItem/resolve request to get CompletionItem.detail. Is it because details are expensive to calculate right away?

Any chance of having CompletionItem.detail without an additional completionItem/resolve request?

(We do call completionItem/resolve to get CompletionItem.documentation when needed, so keeping documentation lazy is fine for us. The story with CompletionItem.detail is technically trickier in our IDEs.)

If I read the LSP spec correctly, the server should take into account the client capability textDocument.completion.completionItem.resolveSupport.properties and has the right to calculate lazily only what the client lists there. Our IDEs list only the documentation property there.

Many thanks for maintaining the LSP server as a standalone tool!

[thecrypticace]

By default the request can only delay the computation of the detail and documentation properties. Since 3.16.0 the client can signal that it can resolve more properties lazily. This is done using the completionItem#resolveSupport client capability which lists all properties that can be filled in during a ‘completionItem/resolve’ request.

This reads to me like you should always expect the possibility of the detail field being null — this is because even if a client is using a later LSP version the server it's communicating with may not.

Having said that I'll look into it as we do some CSS serialization during the resolve step.

My guess is that it's probably not that expensive when connected to a Tailwind CSS v3+ project and it could be provided. But it might adversely affect the performance of completions in v2 or earlier. I'm not 100% sure though. I'll need to do some benchmarking.

[alexander-doroshko]

Thanks for having a look! I think you are right regarding the spec.

it's probably not that expensive when connected to a Tailwind CSS v3+ project and it could be provided

That would be great even if v2 has to stay with lazy details.

[thecrypticace]

@alexander-doroshko Hey — apologies for the late reply. I did some testing today and, unfortunately, it still seems like there can be a significant slowdown (~80%) for completions if we fill these in — likely because we'd be generating rules and the resulting CSS for around 12,000 classes (and possibly more).

I still think this is a great idea to do if we can. But it seems like it might have to wait for Tailwind v4 to see if we can architect it in a way that makes this a non-issue — sorry :(

[alexander-doroshko]

Ok, understood, thanks for taking a look.