How to get VSCode to use different Go env vars for different directories in the same repo?

[Michael-F-Ellis]

This may or may not be something vscode-go should address.

I ran into a problem with a repository that builds a WebAssembly front end and a server for the backend. The issue was how to pass the required GOOS and GOARCH values when linting the wasm code. I found a solution using VSCode Multi-Root Workspaces, but it required changing my project folder structure and learning the intricacies of .code-workspace and friends.

Please see my original question and detailed answer here on StackOverflow and a related thread on golang-nuts

It would be nice if vscode-go could infer required env vars from source file build tags. Is that possible?

[hyangah]

yes, currently the multi-root setup is the way to go for configuring different settings per folder.

Automatically inferring the tags without extra user configuration is an interesting idea, and I am afraid correctly implementing it is not trivial if not impossible.

First, the extension provides many different features. Assuming the detection can be automatically done, what features do we want the detected GOOS/GOARCH to be applied to?

• Intellisense and other language features: we need to find a way to plumb this info to the language server as well. x/tools/gopls: improve handling for build tags go#29202 is the uber issue related to this. I think there are a couple of issues around go list that need to be sorted out as well.
• Do we want to plumb the GOOS/GOARCH when invoking tools like external linter, go test, go build, delve, and others based on the folder of the source? I guess that may not be too difficult but may be surprising to some users if it's done silently.
• Terminal - should it be applied to the integrated terminal too? (i.e. as users run go test in the wasm folder, should GOOS/GOARCH env vars be adjusted? etc.) I am afraid it's difficult. If we apply GOOS/GOARCH to the go test or go build invoked by the extension, but don't apply them to terminal, that may confuse some users.

Second, many go projects aim for multi OS/Arch support, and often have the source code in the same directory (sometimes with build tags, sometimes based on file names). Automated detection is impossible in the case.

An alternative option is to have a special setting to let users specify their desired GOOS/GOARCH, but that overlaps a lot with
VSCode's workspace setting (.code-workspace).

[Michael-F-Ellis]

Automatically inferring the tags without extra user configuration is an interesting idea, and I am afraid correctly implementing it is not trivial if not impossible.

Thanks, @hyangah. I thought that might be the case but went ahead and posted the issue anyway to honor a suggestion made in the golang-nuts thread on this topic.

The .code-workspace approach, now that I understand how to use it, is ok for my purposes. It would be nicer if VSCode simply supported per-folder settings.json files without having to use multi-root workspaces. I assume there must be some reason, known to the VSCode team, for not allowing that.

[hyangah]

Found this one: microsoft/vscode#32693

[Michael-F-Ellis]

@hyangah This is the Way.

[hyangah]

Linked the upstream issue from #48 to keep track of the feature support.