gopls: ignore go.work reference, use go.mod

[idiazcir]

Problem encountered Our team and I are facing a problem regarding gopls and VSCode. The product we develop is based on a microservice architecture and it is hosted on a monorepo. Each application (microservice) is a module with a go.mod. We also have a folder with custom packages developed by us, that are used in one or more applications with different versions.

.
├── apps
│   ├── app1
│   │   ├── go.mod 
│   │   └── go.sum           
│   └── app2
│       ├── go.mod 
│       └── go.sum  
└── pkg
    ├── pkg1
    │   ├── go.mod 
    │   └── go.sum           
    └── pkg2
        ├── go.mod 
        └── go.sum  

In order for VSCode to be able to find each module, we have had to add a go.work file in the root of the repository. Although we do not use go workspace for anything else (we have GOWORK=off). It is only used for VSCode.

The problem is that gopls will not look at the versions of the modules (as defined on their go.mod). If we have app1 using pkg1 version X and app2 using pkg1 version Y, gopls will lint based on the current version of the module pkg1 on the workspace. When the code is compiled, it works fine because golang uses go.mod to determine the version, but gopls doesn't, it uses the go.work. Therefore in VSCode it shows errors all over the code because the versions of the package imported do not match with the current version of the package on the repository.

Possible solutions We consider that possible solutions to this problem may be to:

• Allow gopls to ignore the go.work, and use the go.mod as a reference for the package version used.
• If there is a vendor folder, use the version that the vendor contains.

If there are known solutions to this problem with the current implementation, we are more than happy to hear them out! We haven't been able to find any directly tackling this issue.

[hyangah]

Have you tried to remove the go.work from the root? The zero-config gopls available with gopls v0.15.0+ should address many issues that required users to add go.work to workaround. https://github.com/golang/tools/releases/tag/gopls%2Fv0.15.0

If you added go.work just because old gopls needed it, please remove it. go.work is still useful when you need to work on both app1 and pkg1 in the repo. If you want app1 to work with pkg1 version X (whose source is in the module cache), you won't need to use go.work with gopls v0.15+.

[idiazcir]

Thank you! Updating the gopls to the current version (0.15.3) and removing the go.work solves the issue.