zed
zed copied to clipboard
Astro language server fails to start
Check for existing issues
- [X] Completed
Describe the bug / provide steps to reproduce it
The astro-language-server fails to start, here is the message from the log: 2024-02-22T05:22:18-05:00 [ERROR] failed to start language server "astro-language-server": Request initialize failed with message: Can't find typescript.js or tsserverlibrary.js in node_modules/typescript/lib
Environment
Zed: v0.123.2 (Zed) OS: macOS 14.1.0 Memory: 32 GiB Architecture: x86_64
If applicable, add mockups / screenshots to help explain present your vision of the feature
No response
If applicable, attach your ~/Library/Logs/Zed/Zed.log
file to this issue.
If you only need the most recent lines, you can run the zed: open log
command palette action to see the last 1000.
No response
I'll note that even if you install typescript
in your project, which does fix this particular error, the language server still fails to start with the following error:
2024-02-22T12:41:08+01:00 [ERROR] crates/lsp/src/lsp.rs:274: cannot read LSP message headers
and then every request looks like this:
2024-02-22T12:42:05+01:00 [WARN] Generic lsp request to @volar/language-server failed: server shut down
For the error in the OP, probably that Zed should use its own bundled version of TypeScript, just like it (presumably) does for the TypeScript language server. Or at least, emit a notification in the UI that the server failed to start with the error message.
Logs when attempting to test with cargo run --release
in a new astro project (with typescript) via npm create astro@latest
[2024-02-25T09:17:26-07:00 ERROR util] crates/fs/src/repository.rs:101: Error { code: -9, klass: 4, message: "reference 'refs/heads/master' not found" }
[2024-02-25T09:17:53-07:00 ERROR util] crates/lsp/src/lsp.rs:276: cannot read LSP message headers
[2024-02-25T09:17:53-07:00 ERROR util] crates/editor/src/editor.rs:3655: oneshot canceled
[2024-02-25T09:17:53-07:00 ERROR util] crates/editor/src/editor.rs:3702: oneshot canceled
[2024-02-25T09:17:55-07:00 ERROR util] crates/lsp/src/lsp.rs:298: Broken pipe (os error 32)
Zed: v0.123.6 (Zed) OS: macOS 14.3.1 Memory: 32 GiB Architecture: aarch64 (m1 pro)
same problem, lsp not work in astro
Zed 0.123.6 macOS
/cc @alvgaona could you take a look at the chance if you get a chance?
@maxbrunsfeld I've been looking into it for the past few days. I have some changes attempting to fix it but haven't solved it yet. I'll create a draft PR.
Can repro as well, astro lsp doesn't work :( Zed 0.123.6
Can anyone share any details about the problem that they're seeing. Is anything notable showing up in the language server logs
view, or the zed logs?
Arf, so checking the logs more deeply it seems like it.. might be my fault. The language server is supposed to work even if no instance of Prettier is available, unfortunately a refactor for Volar's 2.0 caused it to throw. I fixed the issue here https://github.com/volarjs/services/pull/81
(though this definitely worked before, and that change was done some time ago now, I assume Zed might've previously provided Prettier to the language server?)
LSP logs for context.
stderr: /<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/volar-service-prettier/index.js:18
stderr: throw new Error("Could not load Prettier: " + e);
stderr: ^
stderr:
stderr: Error: Could not load Prettier: Error: Cannot find module 'prettier'
stderr: Require stack:
stderr: - /<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/volar-service-prettier/index.js
stderr: - /<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/@astrojs/language-server/dist/languageServerPlugin.js
stderr: - /<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/@astrojs/language-server/dist/nodeServer.js
stderr: - /<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/@astrojs/language-server/bin/nodeServer.js
stderr: at Object.create (/<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/volar-service-prettier/index.js:18:23)
stderr: at createServiceContext (/<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/@volar/language-service/lib/languageService.js:156:65)
stderr: at createLanguageService (/<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/@volar/language-service/lib/languageService.js:39:21)
stderr: at Object.getLanguageService (/<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/@volar/language-server/lib/project/typescriptProject.js:74:76)
stderr: at sendDocumentDiagnostics (/<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/@volar/language-server/lib/server.js:278:66)
stderr: at async updateDiagnostics (/<user-path>/Library/Application Support/Zed/languages/astro-language-server/node_modules/@volar/language-server/lib/server.js:267:13)
stderr:
stderr: Node.js v18.15.0
Arf, so checking the logs more deeply it seems like it.. might be my fault. The language server is supposed to work even if no instance of Prettier is available, unfortunately a refactor for Volar's 2.0 caused it to throw. I fixed the issue here volarjs/services#81
(though this definitely worked before, and that change was done some time ago now, I assume Zed might've previously provided Prettier to the language server?)
This fix in Volar/Services still won't keep the LSP from looking for Typescript directly in the project though, right?
Arf, so checking the logs more deeply it seems like it.. might be my fault. The language server is supposed to work even if no instance of Prettier is available, unfortunately a refactor for Volar's 2.0 caused it to throw. I fixed the issue here volarjs/services#81 (though this definitely worked before, and that change was done some time ago now, I assume Zed might've previously provided Prettier to the language server?)
This fix in Volar/Services still won't keep the LSP from looking for Typescript directly in the project though, right?
The client passes the path to TypeScript as an init parameter, so it doesn't have to be in the project I think so?
Arf, so checking the logs more deeply it seems like it.. might be my fault. The language server is supposed to work even if no instance of Prettier is available, unfortunately a refactor for Volar's 2.0 caused it to throw. I fixed the issue here volarjs/services#81 (though this definitely worked before, and that change was done some time ago now, I assume Zed might've previously provided Prettier to the language server?)
This fix in Volar/Services still won't keep the LSP from looking for Typescript directly in the project though, right?
The client passes the path to TypeScript as an init parameter, so it doesn't have to be in the project I think so?
We're passing the TypeScript path from node_modules/@astrojs/language-server
, like other LSP servers such as Svelte and Vue.
I see the fix to 'volar-service-prettier' has been merged. I updated it in my local copy—but I still see log messages from the language server about trouble with prettier:
2024-02-29T15:14:01-05:00 [INFO] Language server with id 1 sent unhandled notification window/showMessage:
{
"message": "Couldn't load `prettier` or `prettier-plugin-astro`. Formatting will not work. Please make sure those two packages are installed into your project.",
"type": 2
}``
Is there anything I can do to fix this locally for me before it's properly fixed?
@3ddyBoi I tried a couple things—but couldn't get it working. Hopefully someone that understands the problem will get it fixed soon. I noticed there was a bug fix related to prettier in the latest pre-release, but it doesn't seem to solve the problem with Astro LSP. ¯_(ツ)_/¯
Sorry for the delay, we're currently working on a lot of things at Astro and I haven't found time for an upstream fix for this.
FWIW, the upstream fix probably won't fix this fully, it fixes a "bad path" being worse than it should, and a fix on Zed's side could make this work right now.
I wonder if locally, installing typescript
, prettier
and prettier-plugin-astro
into your project would make it work?
Sorry for the delay, we're currently working on a lot of things at Astro and I haven't found time for an upstream fix for this.
No need to apologize—that's life on the bleeding edge. FWIW—I've tried installing those locally to the project, but no joy.
@Princesseuh I'm using Astro with Zed without prettier
and prettier-plugin-astro
installed but it seems that Astro has them built-in. Does anyone have issue with auto-completion with <style/>
included in .astro
file?
Hey, the upstream issue has been fixed and the server should not crash anymore when Prettier and the Astro plugin are not present. If it still doesn't work - the issue is most likely on Zed side, as it works in VS Code and Neovim.
I'm still seeing the Volar failure warnings, but the Astro server looks fine 🚀
[WARN] Generic lsp request to @volar/language-server failed: server shut down
[ERROR] crates/lsp/src/lsp.rs:327: Broken pipe (os error 32)
FWIW, with "2.8.0" of the language-server I still see the same message in the logs:
2024-03-12T12:04:41-04:00 [INFO] Language server with id 1 sent unhandled notification window/showMessage: { "message": "Couldn't load
prettieror
prettier-plugin-astro. Formatting will not work. Please make sure those two packages are installed into your project.", "type": 2 }
And still don't get any completions/code actions in astro templates.
FWIW, with "2.8.0" of the language-server I still see the same message in the logs:
2024-03-12T12:04:41-04:00 [INFO] Language server with id 1 sent unhandled notification window/showMessage: { "message": "Couldn't load
prettieror
prettier-plugin-astro. Formatting will not work. Please make sure those two packages are installed into your project.", "type": 2 }
And still don't get any completions/code actions in astro templates.
Yes, the message is normal, what was fixed is that it crashed previously when those packages were missing, when it should just warn (as it does in your log)
OK, so I guess we're back to just not knowing why completions/linting aren't working.
So... should I just close this in favor of a new issue around why there are no completions or linting in the Astro files?
Not really sure what to do—but it's hard to choose Zed over VSCode when working on my Astro projects at the moment because aside from syntax highlighting the Astro integration is not really doing much for me.
So... should I just close this in favor of a new issue around why there are no completions or linting in the Astro files?
Not really sure what to do—but it's hard to choose Zed over VSCode when working on my Astro projects at the moment because aside from syntax highlighting the Astro integration is not really doing much for me.
Hey, Bryan. I see you're hyped about Zed and that's awesome; remember Zed it's in its early stages and a lot of things are probably going on. Also, Astro support was added by Zed supporters like me, we just need to be patient.
This one looks pretty confusing but surely one of us will work it out.
Honestly, wasn't trying to be pushy—I can just leave it I guess.
I don't have this issue, which is puzzling...
You do get autocompletion on .astro
files?
Facing the same issue. Color syntaxing and formatting works fine but I have no autocompletion on anything, not the script section or the html. The LSP server seems to just return empty completion for some reason. If I hit command space in an astro file, regardless of the content of the file I get this sort of messages:
// Send:
{"jsonrpc":"2.0","id":38,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":3,"character":0}}}
// Receive:
{"jsonrpc":"2.0","id":38,"result":{"isIncomplete":false,"items":[]}}
// Send:
{"jsonrpc":"2.0","id":39,"method":"textDocument/documentHighlight","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":6,"character":6}}}
// Receive:
{"jsonrpc":"2.0","id":39,"result":[]}
// Send:
{"jsonrpc":"2.0","id":40,"method":"textDocument/documentHighlight","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":6,"character":6}}}
// Receive:
{"jsonrpc":"2.0","id":40,"result":[]}
// Send:
{"jsonrpc":"2.0","id":41,"method":"textDocument/codeAction","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"range":{"start":{"line":6,"character":6},"end":{"line":6,"character":6}},"context":{"diagnostics":[],"only":["","quickfix","refactor","refactor.extract","source"]}}}
// Receive:
{"jsonrpc":"2.0","id":41,"result":[]}
// Send:
{"jsonrpc":"2.0","id":42,"method":"textDocument/documentHighlight","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":6,"character":7}}}
// Receive:
{"jsonrpc":"2.0","id":42,"result":[]}
// Send:
{"jsonrpc":"2.0","id":43,"method":"textDocument/documentHighlight","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":6,"character":7}}}
// Receive:
{"jsonrpc":"2.0","id":43,"result":[]}
// Send:
{"jsonrpc":"2.0","method":"textDocument/didChange","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro","version":10},"contentChanges":[{"range":{"start":{"line":6,"character":7},"end":{"line":6,"character":7}},"text":" "}]}}
// Send:
{"jsonrpc":"2.0","id":44,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":6,"character":8}}}
// Receive:
{"jsonrpc":"2.0","id":44,"result":{"isIncomplete":false,"items":[]}}
// Send:
{"jsonrpc":"2.0","id":45,"method":"textDocument/documentHighlight","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":6,"character":8}}}
// Receive:
{"jsonrpc":"2.0","id":45,"result":[]}
// Send:
{"jsonrpc":"2.0","id":46,"method":"textDocument/hover","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":6,"character":7}}}
// Send:
{"jsonrpc":"2.0","id":47,"method":"textDocument/codeAction","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"range":{"start":{"line":6,"character":8},"end":{"line":6,"character":8}},"context":{"diagnostics":[],"only":["","quickfix","refactor","refactor.extract","source"]}}}
// Receive:
{"jsonrpc":"2.0","id":46,"result":null}
// Receive:
{"jsonrpc":"2.0","id":47,"result":[]}
// Receive:
{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///project-path/src/pages/index.astro","diagnostics":[],"version":10}}
// Receive:
{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///project-path/src/pages/index.astro","diagnostics":[],"version":10}}
// Receive:
{"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///project-path/src/layout/default.astro","diagnostics":[],"version":0}}
// Send:
{"jsonrpc":"2.0","id":48,"method":"textDocument/definition","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":6,"character":7}}}
// Receive:
{"jsonrpc":"2.0","id":48,"result":[]}
// Send:
{"jsonrpc":"2.0","id":49,"method":"textDocument/definition","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":6,"character":7}}}
// Receive:
{"jsonrpc":"2.0","id":49,"result":[]}
// Send:
{"jsonrpc":"2.0","id":50,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:///project-path/src/pages/index.astro"},"position":{"line":6,"character":8}}}
// Receive:
{"jsonrpc":"2.0","id":50,"result":{"isIncomplete":false,"items":[]}}
So I'm not sure where to look since it seems to be working, just returning empty results for everything.
This is on Zed 0.133.5
I don't have this issue, which is puzzling...
You do get autocompletion on
.astro
files?
Nope. Autocomplete won't work because of this issue. The LSP seems to fail, and wondering when this could be fixed.
We're working on something upstream that might fix this (mostly by coincidence), but I can't guarantee anything