Ask questionsx/tools/gopls: support multi-module workspaces
I'm using go version
go1.12.5 darwin/amd64 and the latest gopls release and the latest go extension in VSCode.
So I'm working a a project with a rather weird project structure for a Go project. It's a mono-repo of sorts. Here is the basic structure:
<config_files> services/ - go_service1 - go_service2 README.MD
I usually open up the entire workspace in VSCode when I work in this project. With that I've noticed a rather weird (or maybe not) behaviour from
You see it's looking at code in the wrong mod versions. I've discovered that it's because it's reading a
go.mod file that were in the root of the workspace - which has since been removed. That
go.mod file contained an old version of a module. Even though I were actually working in
go_service1 it preferred that one. I realized it's most likely because VSCode is invoking
gopls from the workspace level, since it works perfectly if i open up either of the service-folders in a separate window.
I didn't find any flags that I could set in
gopls. Is it possible to configure how gopls works with modules? To properly support working in monorepo's like this?
This issue were spawned from this discussion: https://github.com/microsoft/vscode-go/issues/2490
Answer questions ermik
I am assuming it's possible the same logic that Go uses to figure out how to build modules with submodules expressly defined (handling submodules with
go.mod files, rather than inferred) to create a set of subtreet contexts. Figure out which
go.mod subtree the currently edited file belongs to when it is edited and change the context for go toolchain calls.
Another issue is program-scope linting. If I change inner-most modules I want to see which code paths that change turned
red. Assuming one can relate
go.mod contexts to each other, we could subsequently run the toolchain on the root context or even recursively run it on the ancestors until reaching the root for the currently open file to see the change impact up the tree.