Yes, gopls is mostly used by the editor. However, gopls does some good static checks that are not performed by "go vet" or "go fix". I Iike to perform static linter checks on the command line as part of my development process.
Running gopls on the command line works well with individual files but not well with packages. You can't just specify the path to a package, you have to list all the files in the package. My script is just a way of automating that. It walks the source tree and calls "gopls check" with *.go wildcard for each package. The best solution would be for "gopls check" to accept the ./... package specifier, like other go tools do. If gopls was enhanced in that way I would have no need for the script. On Thursday, 5 March 2026 at 07:32:36 UTC Xie Yuchen wrote: > Hi Stephen, may I know your context of gopls check usage? Gopls is mostly > used by editor so the editor passes the filenames for every opened file. > > The command right now works, but a wildcard feature is helpful in your > case. > On Thursday, February 19, 2026 at 11:00:51 PM UTC+8 Michael Oguidan wrote: > >> thank you very much, very useful >> >> On Monday, February 16, 2026 at 3:06:18 PM UTC Stephen Illingworth wrote: >> >>> I want to run the gopls analsysers on all the files in my project. I was >>> hoping something like the following would work: >>> >>> gopls check ./... >>> >>> But unfortunately, "gopls check" only works with filenames and the ./... >>> is for packages. >>> I really want to only check the files in each package in turn. >>> >>> I've created the following bash script to do what I need: >>> >>> https://gist.github.com/JetSetIlly/0cb4fb553df41e7dfba134ec4fb78cc7 >>> >>> Usage: GOPLS_CHECK <PATH> [QUIET] >>> >>> It works by finding all packages in the specified path and running an >>> instance of "gopls check" for the files in each package. The number of >>> "gopls check" running in parallel at any one time is limited to the number >>> of CPU cores. >>> >>> By default, the script will print out the names of the packages it is >>> checking. This can be suppressed with the optional QUIET argument. When >>> QUIET is set then only the output from gopls itself is printed. >>> >>> Besides gopls, all commands should be available on any system with bash >>> installed (xargs, dirname, etc.) >>> >>> >>> >>> A simpler way of doing this would be to pass every file in the entire >>> project to "gopls check" in one gulp. This didn't work well for me, >>> seemingly because of the presence of build tags in some of my packages. The >>> method described above works better for my purposes. >>> >>> I'm posting because I thought that it might be useful to other people. >>> I'm also curious if there are existing solutions. I was surprised at not >>> being able to find an existing way to run the gopls analysers in this >>> fashion. >>> >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/071f87b4-853d-463e-98c9-3ea6c1274c8en%40googlegroups.com.
