As of 4d506bd, GopherJS has almost complete support for Go modules. Like the go tool, gopherjs operates in one of two modes: module mode, or GOPATH mode. The logic behind mode selection matches the go tool.

• In GOPATH-mode, the build tag gopherjsdev can be supplied to gopherjs to instruct GopherJS not to use its compile-time version of github.com/gopherjs/gopherjs/.... In module-mode, the compiled versions of these packages are never used; they must always be resolvable via go.mod
• None of GopherJS's commands (install, build etc) install dependencies by default. This is now much more in line with the behaviour of the go tool as a result of the build cache changes in Go 1.10. gopherjs install only installs packages listed directly on the command line. Instead, a build cache is maintained and used which is much more robust when it comes to avoiding staleness.
• gopherjs run can now take a single package argument. e.g. gopherjs run . or gopherjs run example.com/hello. The interpretation of arguments matches the go tool, as described in https://github.com/golang/go/issues/22726
• gopherjs serve behaves slightly differently in module-mode when it comes to listing modules/packages. In GOPATH mode, it is possible to list directory contents beneath $GOPATH/src. There is not such concept in module-mode. Instead, the path must be to a valid module or package within a module in order for a list to succeed.

• There is not yet support for the go tool flags -mod=readonly|vendor