Closed joerdav closed 6 months ago
Copied from https://github.com/a-h/templ/issues/630
I have the same issue. I'm using Goland 2023.3.6 and Goland 2024.1 Release Candidate.
Also, I'm experiencing inconsistent code completion with the templ tool. I followed the installation instructions (go install... and go get...) and installed the plugin, but I'm unsure if additional setup is required.
Since I installed the latest version I even hat some crashes when working on templ files. Not very concerning (I'm also using some beta-versions of plugins) but mentionable.
The latest version of the plugin contains some config options that will aid in troubleshooting. I've updated the docs, however the new plugin version is still in the approval process.
https://templ.guide/commands-and-tools/ide-support#troubleshooting-1
Same here. In my case it only works like 10% of the time, to a point that I consider it to not being slow but not working at all.
This on:
And I dont see much when tracking the logs for troubleshooting, just:
{"level":"error","ts":"2024-04-09T14:48:16+08:00","caller":"proxy/client.go:65","msg":"unable to complete because the sourcemap for the URI doesn't exist in the cache","uri":"file:///C:xxxxxxxxxxx
And:
{"level":"warn","ts":"2024-04-09T14:48:16+08:00","caller":"proxy/server.go:380","msg":"completion: got gopls error","error":"context canceled"}
@heagma if you enable troubleshooting, can you see anything on the web server?
You should see a file that matches the URI that is mentioned in that error log.
@joerdav The file mentioned in the error is just my template file. The full line is:
{"level":"error","ts":"2024-04-09T14:48:16+08:00","caller":"proxy/client.go:65","msg":"unable to complete because the sourcemap for the URI doesn't exist in the cache","uri":"file:///C:xxxxx/internal/templates/home.templ", "stacktrace":"github.com/a-h/templ/cmd/templ/lspcmd/proxy.Client.PublishDiagnostics
C:/Users/xxxxx/go/pkg/mod/github.com/a-h/templ@v0.2.648/cmd/templ/lspcmd/proxy/client.go:65
github.com/a-h/protocol.clientDispatch
C:/Users/xxxxx/go/pkg/mod/github.com/a-h/protocol@v0.0.0-20230224160810-b4eec67c1c22/client.go:102
github.com/a-h/protocol.NewClient.ClientHandler.func1
C:/Users/xxxxx/go/pkg/mod/github.com/a-h/protocol@v0.0.0-20230224160810-b4eec67c1c22/client.go:36
github.com/a-h/protocol.Handlers.ReplyHandler.func1
C:/Users/xxxxx/go/pkg/mod/go.lsp.dev/jsonrpc2@v0.10.0/handler.go:35
github.com/a-h/protocol.Handlers.AsyncHandler.func2.2
C:/Users/xxxxx/go/pkg/mod/go.lsp.dev/jsonrpc2@v0.10.0/handler.go:114"}
Also, the gopls is not outputting anything on the logs (I confirmed it is running on Windows task manager), only the templ is giving any sort of info:
Sorry, what I mean is the debug web server, if you look in the trouble shoot guide it gives a value to put in the http
option of the extension, this should start a web server that exposes the internal state of the plugin, it would be useful for troubleshooting to see that page :)
Yes, the server displays the filename with few links (source code for .templ
/.go
files), nothing else :
I used to only encounter inconsistency with the code suggestion. Now, I actually encounter slow LSP as well. The Go Templ VSCode is working fine without any issues. In the image below, the suggestion keeps on loading in Goland. Image: Goland.
In VSCode, the suggestion can run without any problems. Image: VSCode.
Here is what I observed. This issue happens with importing struct from outer package. For example, I tried to use a struct belonging to another package. Templ was not able to load the suggestion.
However, if I include the struct inside the same page, it worked.
By the way, I think the issue is now resolved by Goland 2024.1.1. I no longer had the slow response from templ and all completion now is working fine.
Before the 2024.1.1 version, Goland had issue with the code inspection. Therefore, I assume that this was the root cause.
Image: Code completion is now working.
Image: Release note of Goland 2024.1.1
Tried the recently updated Goland 2024.1.1 (April 30th) and the issue indeed seems to be gone.
Okay, great outcome! I'll close this for now and we can track any other issues seperately.
@ainsleyclark