Skip to content

Language Server throws when textDocument client capability is missing #1251

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
cowboyd opened this issue Mar 5, 2025 · 2 comments · Fixed by #1252
Closed

Language Server throws when textDocument client capability is missing #1251

cowboyd opened this issue Mar 5, 2025 · 2 comments · Fixed by #1252
Assignees
Labels
bug Something isn't working

Comments

@cowboyd
Copy link

cowboyd commented Mar 5, 2025

What version of VS Code are you using?

N/A

What version of Tailwind CSS IntelliSense are you using?

0.14.8

What version of Tailwind CSS are you using?

N/A

What package manager are you using?

npm

What operating system are you using?

macOS

Tailwind config

N/A

VS Code settings
N/A

Reproduction

To reproduce, run the lspx shell against any version of the language server:

deno run -A jsr:@frontside/lspx --interactive --lsp "tailwindcss-language-server --stdio"

Then, when prompted enter the command initialize({"capabilities": {}}) into the prompt:

LSP> initialize({"capabilities": {}})

Describe your issue

The tailwind language server throws an error when there are no textDocument capabilities on the client to which it is attached.

LSP> initialize({"capabilities": {}})
Sending request initialize with params [{"capabilities":{}}]...
Error: Request initialize failed with message: Cannot read properties of undefined (reading 'hover')

The spec indicates that textDocument is an optional property https://github.com/microsoft/vscode-languageserver-node/blob/df05883f34b39255d40d68cef55caf2e93cff35f/protocol/src/common/protocol.ts#L1098

While it is very rare that this should happen, it is still a possibility, and the language server should handle it gracefully.

@thecrypticace
Copy link
Contributor

Heh, interesting. We definitely shouldn't throw but I'm not actually sure what the right behavior is here. Since the spec says that clients must support textDocument/didOpen, textDocument/didChange (+ both full and incremental sync), and textDocument/didClose I guess the capability is probably more about things you can do with a document once it's open.

afaik it doesn't really make much sense for our server to interact with a client that doesn't advertise this capability but I'll need to do a bit of research to figure out what the right behavior is in this case.

@thecrypticace thecrypticace self-assigned this Mar 5, 2025
@thecrypticace thecrypticace added the bug Something isn't working label Mar 5, 2025
@thecrypticace thecrypticace changed the title language server throws error if textDocument client capability is not present in initialization params Language Server throws when textDocument client capability is missing Mar 5, 2025
@thecrypticace
Copy link
Contributor

Gonna tag a release of the language server with a fix today

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants