search

gopherjs / gopherjs

A compiler from Go to JavaScript for running Go code in a browser
BSD 2-Clause "Simplified" License
12.68k stars 566 forks source link

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

Open flimzy opened 1 year ago

flimzy commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 😕