gopherjs: Vendoring gopherjs code causes generated js to fail
I have a piece of go that imports gopherjs
package main
import (
"github.com/gopherjs/gopherjs/js"
)
func main() {
js.Global.Set("mypackage", map[string]interface{}{
"DoSomething": DoSomething,
})
println("gopher bindings loaded")
}
func DoSomething() {
print("done!")
}
I then vendor gopherjs and try to do a gopherjs build. the command succeeds but the generated code fails as soon as it tries to use ‘js.Global.Set’ because of nil pointer.
If I then delete the vendor/ directory and rebuild everything works fine.
Is there something else I should be vendoring in order for this to work? Or what is the expected workflow?
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 20 (10 by maintainers)
Commits related to this issue
- make.go: remove --use_gopath Because it makes full integration with gopherjs impossible (without polluting the user's GOPATH), as long as https://github.com/gopherjs/gopherjs/issues/415 is not fixed.... — committed to perkeep/perkeep by mpl 8 years ago
- detect js package by /gopherjs/js suffix This should allow vendoring. (#415) — committed to gopherjs/gopherjs by neelance 8 years ago
- README: Document that using vendored GopherJS is currently not supported. GopherJS itself supports vendoring, but vendoring _it_ into your project is currently not supported. Issue #415 tracks the p... — committed to gopherjs/gopherjs by dmitshur 8 years ago
- README: Document that using vendored GopherJS is currently not supported. GopherJS itself supports vendoring, but vendoring _it_ into your project is currently not supported. Issue #415 tracks the p... — committed to gopherjs/gopherjs by dmitshur 8 years ago
- Add support for vendoring gopherjs * Determines whether there is an import path to a vendored version of gopherjs * If so, updates all import paths to gopherjs in generated code to use the vendor... — committed to nmiyake/gopherjs by nmiyake 7 years ago
- Add support for vendoring gopherjs * Determines whether there is an import path to a vendored version of gopherjs * If so, updates all import paths to gopherjs in generated code to use the vendor... — committed to nmiyake/gopherjs by nmiyake 7 years ago
- Add support for vendoring gopherjs * Determines whether there is an import path to a vendored version of gopherjs * If so, updates all import paths to gopherjs in generated code to use the vendor... — committed to nmiyake/gopherjs by nmiyake 7 years ago
- dep init Also ignore github.com/gopherjs/gopherjs/js -- it cannot be vendored See: https://github.com/gopherjs/gopherjs/issues/415 Fixes https://gitlab.com/agamigo/material/issues/16 CI: Don't need... — committed to agamigo/material by bzub 6 years ago
- build: Load js, nosync packages from gopherjspkg rather than GOPATH. The Go stdlib overrides (i.e., compiler/natives package) are already embedded into the GopherJS build system. This makes it possib... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- build, compiler/typesutil: Don't use vendor directory to resolve js, nosync. These core GopherJS packages are already embedded into the GopherJS build system via the gopherjspkg virtual filesystem. T... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- build: Load js, nosync packages from gopherjspkg rather than GOPATH. The Go stdlib overrides (i.e., compiler/natives package) are already embedded into the GopherJS build system. This makes it possib... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- build, compiler/typesutil: Don't use vendor directory to resolve js, nosync. These core GopherJS packages are already embedded into the GopherJS build system via the gopherjspkg virtual filesystem. T... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- build: Load js, nosync packages from gopherjspkg rather than GOPATH. The Go stdlib overrides (i.e., compiler/natives package) are already embedded into the GopherJS build system. This makes it possib... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- build, compiler/typesutil: Don't use vendor directory to resolve js, nosync. These core GopherJS packages are already embedded into the GopherJS build system via the gopherjspkg virtual filesystem. T... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- build: Load js, nosync packages from gopherjspkg rather than GOPATH. The Go stdlib overrides (i.e., compiler/natives package) are already embedded into the GopherJS build system. This makes it possib... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- build, compiler/typesutil: Don't use vendor directory to resolve js, nosync. These core GopherJS packages are already embedded into the GopherJS build system via the gopherjspkg virtual filesystem. T... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- tests: Include stderr in TestGopherJSCanBeVendored output. This way, we get more information when/if TestGopherJSCanBeVendored fails. Before: $ go test -v -run=TestGopherJSCanBeVendored === RUN ... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- tests: Include stderr in TestGopherJSCanBeVendored output. This way, we get more information when/if TestGopherJSCanBeVendored fails. Before: $ go test -v -run=TestGopherJSCanBeVendored === RUN ... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- build: Load js, nosync packages from gopherjspkg rather than GOPATH. The Go stdlib overrides (i.e., compiler/natives package) are already embedded into the GopherJS build system. This makes it possib... — committed to gopherjs/gopherjs by dmitshur 6 years ago
- build, compiler/typesutil: Don't use vendor directory to resolve js, nosync. These core GopherJS packages are already embedded into the GopherJS build system via the gopherjspkg virtual filesystem. T... — committed to gopherjs/gopherjs by dmitshur 6 years ago
Now that GopherJS 1.10-1 is out, I’ll be prioritizing resolving this issue in the coming weeks. I think it’s becoming more important to be able to vendor GopherJS, and be able to use fixed versions of it (rather than always counting on the latest).
The PR just needs to be reviewed and tested.
You already have! I will make this issue my priority for the coming weekend.
You should be able to use Go 1.10 even before this is resolved. I’ll want to chime in on that issue when I’m working on this.
Thank you very much, but I’d be worried that I only did a part of all the work required to resolve this issue (I’ve never been paid to work on an open source issue before, so I’m not sure how to deal with it). Maybe you’d want to buy me a coffee instead. But this weekend is still the soonest I can get to it, because I’ll need a large continuous time block.
@shurcooL, this is holding up Perkeep getting rid of its hacky
make.gowrapper that builds a temp dir parallel GOPATH to work around pre-Go 1.10 cmd/go bugs. We want to just use Go 1.10 without GOPATH tempdir hackery.Can we incentivize you to fix this? We have some budget (https://opencollective.com/perkeep) and could pay for your time.
I’ve created PR #787 that should resolve this issue.
In my testing, I was able to vendor the entire GopherJS project in another Go project, and then used it to successfully build Go code (including Go code that imports
github.com/gopherjs/gopherjs/jspackage). This was done without the (normal, non-vendored) GopherJS repository in GOPATH.I think everything should work, but it’s possible I’m not aware of some other ways people are vendoring GopherJS. Please feel free to test the PR and let me know if vendoring doesn’t work for you.
@shurcooL I’m sure you’re still busy, but I was curious if there was any update for this issue?