Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
This document is evolving and changing as new decisions are made. If you have a question not answered here, please create an issue.
GopherJS aims to follow the Go style, as described in Effective Go and Go Code Review Comments. All new code should follow those rules. There should be no
go vet issues. Only exception is if editing existing code that doesn't yet follow Go style, it's acceptable to leave style change out of scope.
See this discussion.
GopherJS relies on standard
//go:generate directives to generate code. Running
go generate github.com/gopherjs/gopherjs/... && go install -v github.com/gopherjs/gopherjs
should regenerate all packages and reinstall
gopherjs. You may need extra dependencies for generation:
go get -u github.com/shurcooL/vfsgen/cmd/vfsgendev go get -u github.com/shurcooL/httpfs/filter
./compiler/natives package is generated to statically embed the contents of its src subdirectory. If you're changing its contents, you'll need to regenerate that package for it to take effect.
Alternatively, for rapid development, you may build with
gopherjsdev build tag:
go install -v -tags=gopherjsdev github.com/gopherjs/gopherjs
touch $GOPATH/bin/gopherjs so stale GOPATH/pkg/*_js files get rebuilt).
That way, the
natives.FS filesystem will read directly from disk. Read here for more information on
gopherjsdev build tag mode (note that
dev build tag isn't used to avoid overlap with users' projects, see https://github.com/gopherjs/gopherjs/issues/645).
If your pull request contains changes to that package, it should include the regenerated files.
At this time, GopherJS only uses ECMAScript 5 features.
Usually when you use ES6 features you have a compiler like Babel + polyfills to make it compatible with older browsers. Obviously that's not an option for GopherJS. I don't want to sacrifice compatibility just for some nicer syntax in generated files. If you find some major performance gain, then we can talk about it. Otherwise I'd like to stick with widely supported features.
See issue #320.