$GOPATH/src/github.com/gopherjs/gopherjs/js used during compilation

[flimzy]

If $GOPATH/src/github.com/gopherjs/gopherjs/js happens to exist at the time GopherJS is compiled, this version of the package is used rather than the version embedded in the virtual file system. This can lead to an unusable gopherjs binary, in the case of mismatched versions.

[nevkontakte]

I suspect this isn't so much as our bug as go/build one. This would be a great deal easier to fix after https://github.com/gopherjs/gopherjs/issues/1021, especially if we switch to go/packages instead of go/build (which support for modules is incomplete and somewhat buggy).

[flimzy]

Your comment got me thinking... it would be strange for the actual compilation process to use $GOPATH/src in module mode... so makes me wonder if this is a problem with go generate. I'll do some investigation to try to pin down the cause. If it is related to generating our VFS, then the switch to embed may help.

[nevkontakte]

So here we fall back to the embedded VFS if the primary build context doesn't find a package. This was done to avoid weirdness when a projects go.mod specifies a particular version of the js package. The problem is that go/build shouldn't look for packages in $GOPATH when working in the go.mod environment, but I bet because modules support was retrofitted into it as an afterthought it still prioritizes $GOPATH 😕