Vendoring gopherjs code causes generated js to fail #415

Open
benechols-wf opened this Issue Mar 1, 2016 · 8 comments

Projects

None yet

4 participants

@benechols-wf

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?

@shurcooL
Member
shurcooL commented Mar 1, 2016

Thanks for reporting.

I'm guessing it happens because the github.com/gopherjs/gopherjs/js import path is special (just like the "C" import path that cgo uses), and we're probably not taking into account that it can change when gopherjs is vendored to be example.com/user/repo/vendor/github.com/gopherjs/gopherjs/js.

@benechols-wf

Quick question related to this -- if I vendor the stdlib overrides(gopherjs/compiler/natives/...) into vendor/github.com/gopherjs/gopherjs will those be used instead of looking for them in $GOPATH ?

@neelance
Member
neelance commented Mar 2, 2016

It will always use those form the GOPATH. Vendoring in this context not possible on a theoretical level, unless we come up with some special vendoring rule. E.g. when GopherJS wants to compile net/http, then this resolves to the normal package in GOROOT. There is no vendor directory in this context.

And yes, the github.com/gopherjs/gopherjs/js import path is special and if the package is vendored then it is not recognized any more. I am not sure if we should fix this, because it is mandatory that the versions of the js package and the used GopherJS compiler are the same. Vendoring the js package could make it go out of sync, which is dangerous.

@benechols-wf

I want to vendor all of gopherjs and my build process will build gopherjs from the vendored version. Then there will never be mismatched versions :)

@benechols-wf

I guess our build process could take the vendored version and copy it back into the GOPATH during the build but that seems bad to me.

@mpl
mpl commented May 6, 2016

@neelance As @benechols-wf notes, one hits that bug even when one wants to simply vendor the whole of github.com/gopherjs/gopherjs into a project (which should be a pretty common use case), which would not make github.com/gopherjs/gopherjs/js out of sync wrt to github.com/gopherjs/gopherjs.

So it should definitely be fixed imho.

@camlistorebot camlistorebot pushed a commit to camlistore/camlistore that referenced this issue May 9, 2016
@mpl mpl make.go: remove --use_gopath
Because it makes full integration with gopherjs impossible (without
polluting the user's GOPATH), as long as
gopherjs/gopherjs#415 is not fixed.

Also it is kind of antithetical with the point of make.go anyway.

We still rely on CAMLI_MAKE_USEGOPATH for the integration tests that run
make.go to know that they shouldn't recursively create another temp
GOPATH (when they're already in such a temp dir, because they're started
through devcam test).

Change-Id: Icc6af46ec5976fdf08e9b8bf4249e307a15499cf
93a7f46
@neelance neelance added a commit that referenced this issue May 14, 2016
@neelance neelance detect js package by /gopherjs/js suffix
This should allow vendoring. (#415)
f627518
@neelance
Member

This will probably still run into #462. Working on it.

@mpl
mpl commented May 20, 2016

@neelance jsyk, I was hoping f627518 and 2e16c68 had fixed this , so I've just retried, and it still does not seem to work for me.

Layout is like this:

$HOME/project/build-env/
    src/
        app/ui/gopherjs/main.go
        app/vendor/github.com/gopherjs/gopherjs
        app/vendor/github.com/gopherjs/gopherjs/js
    pkg/
    bin/

GOPATH=$HOME/project/build-env/

using gopherjs as:

$HOME/project/build-env/bin/gopherjs build -m -o $HOME/project/build-env/app/ui/gopherjs.js app/ui/gopherjs

and getting this error:

exit status 1, cannot find package "github.com/gopherjs/gopherjs/js" in any of:
    /home/mpl/go1/src/vendor/github.com/gopherjs/gopherjs/js (vendor tree)
    /home/mpl/go1/src/github.com/gopherjs/gopherjs/js (from $GOROOT)
    /home/mpl/project/build-env/src/github.com/gopherjs/gopherjs/js (from $GOPATH)
exit status 1

So it seems like it's still not looking for github.com/gopherjs/gopherjs/js in the vendor dir of my project.

@shurcooL shurcooL added a commit that referenced this issue Oct 18, 2016
@shurcooL shurcooL README: Document that using vendored GopherJS is currently not suppor…
…ted.

GopherJS itself supports vendoring, but vendoring _it_ into your project
is currently not supported. Issue #415 tracks the progress on fixing that.

Helps #415.
Updates #537.
5e8a800
@shurcooL shurcooL added a commit that referenced this issue Oct 18, 2016
@shurcooL shurcooL README: Document that using vendored GopherJS is currently not suppor…
…ted.

GopherJS itself supports vendoring, but vendoring _it_ into your project
is currently not supported. Issue #415 tracks the progress on fixing that.

Helps #415.
Updates #537.
64c7aad
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment