deckhouse
chore: update go.work to specify module usage across project
Description
In the language server protocol, a "workspace" consists of a folder along with per-folder configuration. Some LSP clients such as VS Code allow configuring workspaces explicitly, while others do so automatically by looking for special files defining a workspace root (such as a .git directory or go.mod file).
In order to function, gopls needs a defined scope in which language features like references, rename, and implementation should operate. Put differently, gopls needs to infer from the LSP workspace which go build invocations you would use to build your workspace, including the working directory, environment, and build flags.
In the past, it could be tricky to set up your workspace so that gopls would infer the correct build information. It required opening the correct directory or using a go.work file to tell gopls about the modules you're working on, and configuring the correct operating system and architecture in advance. When this didn't work as expected, gopls would often fail in mysterious ways--the dreaded "No packages found" error.
Starting with gopls v0.15.0, workspace configuration is much simpler, and gopls will typically work when you open a Go file anywhere in your workspace. If it isn't working for you, or if you want to better understand how gopls models your workspace, please read on.
Why do we need it, and what problem does it solve?
Improve developer experience
Checklist
- [ ] The code is covered by unit tests.
- [ ] e2e tests passed.
- [ ] Documentation updated according to the changes.
- [ ] Changes were tested in the Kubernetes cluster manually.
Changelog entries
section: ci
type: chore
summary: update go.work to specify module usage across project
