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

[Michael Ellis]

(Sorry for posting what is mostly a VSCode question. I've asked it on StackOverflow without getting any responses.  Am reposting here in the hope that some has already run into this problem and figured out how to deal with it.)

I have a Go project that builds a WebAssembly (WASM)  app and a backend server for it. Both pieces build and run without errors. VSCode, however, produces an annoying linter error in the WASM app.

```

could not import syscall/js (no required module provides package "syscall/js")

```

The problem, as I currently understand it, is that VSCode doesn't infer from the build tags that it should invoke `gopls` with `env GOOS=js GOARCH=wasm` and that one solution is to set these tags as workspace Go environment vars.

The app design, however, relies on providing a common internal package to both the wasm and the server code so that each side sees some struct definitions that simplify the interface between them. To that end, the repo is organized (simplified view) as follows:

```

cmd

├── internal

│   └── common

│       ├── common.go

│       └── common_test.go

├── server

│   └── main.go

└── wasm

    └── main.go

```

How can I configure VSCode to use `env GOOS=js GOARCH=wasm` when linting the wasm directory and not for other directories? 

[Alex]

Try setting ""go.testEnvVars"" and "go.toolsEnvVars"

[Space A.]

Hi,

the solution would be:

1. Protect WASM source files with build flags so that when you open a "backend" main sources, IDE won't complain about "syscall/js", like this:

// +build js,wasm

2. Open `wasm` directory in second instance of VS Code for which you would set GOOS and GOARCH for a workspace. When editing settings in json, click on "workspace" tab and VS Code will create .vscode/settings.json in `wasm` directory. Put something like:

{

    "go.toolsEnvVars": {

        "GOOS": "js",

        "GOARCH": "wasm",

    }

}

in there.

3. In future, work in two instances of VS Code, even though if logically it's a different parts of same project and could be under the same Go module. All IDE features will work fluently. I haven't seen any problems with this approach so far.

суббота, 13 февраля 2021 г. в 23:42:06 UTC+3, michael...@gmail.com:

[Michael Ellis]

Thanks, Space & Alex.  I already understood the need for the Go tool environment vars, just didn't know how to apply them on a per-folder basis.  Thanks for outlining how to use multiple instances of VSCode.  It doesn't appeal to my workflow preferences, but then à chacun son goût as nos amis français would put it.

I ended up learning how to use VSCode Multi-Root Workspaces to permit a separate settings.json in wasm/ folder.  That seems to work fairly well.  I wrote a detailed answer on StackOverflow for anyone who's interested.

Cheers,
Mike

“I want you to act as if the house was on fire. Because it is.” — Greta Thunberg

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/2vI1CA76HPI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/ed6caf0c-64ec-454d-8926-dc9cbb98d8a5n%40googlegroups.com.

[Wojciech S. Czarnecki]

Dnia 2021-02-14, o godz. 10:54:02
Michael Ellis <michael...@gmail.com> napisał(a):

> I wrote a detailed answer on StackOverflow

Thank you.

As vscode-go is now curated by the Go team [https://blog.golang.org/vscode-go]
I think you should raise issue at https://github.com/golang/vscode-go.
Your project layout (original one) seems good and straightforward, and the need
for having per-folder environment settings or build-tags is real.
It shouldn't be the IDE that dictates Go project structure, IMO.

TC,

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Michael Ellis]

As vscode-go is now curated by the Go team [https://blog.golang.org/vscode-go]
I think you should raise issue at https://github.com/golang/vscode-go.
Your project layout (original one) seems good and straightforward, and the need
for having per-folder environment settings or build-tags is real.
It shouldn't be the IDE that dictates Go project structure, IMO.

I agree about wanting project structure independent of IDE.  I'm not so sure if this is something vscode-go can reasonably be expected to solve, though.

If I'm understanding correctly,  vscode-go would need to parse each file for build-tags and pass that information to the go tool chain, presumably as environment variables.

That sounds doable for standard tags that map to supported values for GOOS, GOARCH, etc., but I wonder what problems would be caused by non-standard tags, e.g. "+build mage" for magefiles. 

 

Cheers,
Mike

“I want you to act as if the house was on fire. Because it is.” — Greta Thunberg

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/2vI1CA76HPI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20210214173156.1a9edbfa%40xmint.

[Michael Ellis]

I've opened https://github.com/golang/vscode-go/issues/1225.  

 

[Kevin Chadwick]

> In future, work in two instances of VS Code

I set GOOS env variable and HISTFILE env variable on each code execution. So a particular folder is tied to that OS and the terminal history is separate.

IOW, i make a code app icon for each current project. One also for go stdlib src searches.