-
Notifications
You must be signed in to change notification settings - Fork 562
Developer Guidelines
This page provides guidelines for developers working on GopherJS and its related projects. It may also serve as a list of recommendations for developers of GopherJS libraries and JavaScript bindings, such as those found here.
This document is evolving and changing as new decisions are made. If you have a question not answered here, please create an issue.
Note: These are the effective rules as they've been implemented since push access was granted beyond just the project creator (Richard). See issue 894, for some historical context, when the project changed leadership.
As of 2022/09/06, the list of people that have write access to the GopherJS repository includes:
- @flimzy
- @nevkontakte
- @myitcv
- @hajimehoshi
- @dmitshur
These people have access to review and merge PRs.
A PR may be merged after going through a code review and getting one review from one of these people. A code change may be pushed directly to master without going through code review, but it's preferable to avoid this whenever possible (use your best judgement). It is always okay to revert a breaking change without waiting for code review.
PRs should keep GopherJS functional (generally this means keeping the CI green), not break existing users in huge ways (minor changes to broken things are okay), and try to keep the codebase as simple and easy to maintain (instead of adding complexity and dependencies).
Changes that significantly modify functionality are expected to be discussed in an issue first, looking for an agreement from people with +2 access, before sending a PR for code review.
Please keep in mind that people who are able to review PRs have limited bandwidth. If your PR isn't getting attention, please see issue 894.
GopherJS aims to follow the Go style, as described in Effective Go and Go Code Review Comments. We also use golangci-lint to enforce some project-specific style and linting rules on newly changed code. Most notably, at the moment, we have adopted gofumpt as a stricter style than the standard gofmt. All new code should follow those rules. There should be no go vet issues or other new linter failures added. This is enforced with golaingci-lint, so as long as CI is green, you should be good to go.
See this discussion.
Up to GopherJS 1.12-3, GopherJS loosely followed upstream Go's versioning scheme. Specifically, GopherJS borrowed the upstream major & minor versions, and applied its own patch version with a -X suffix. It was assumed that GopherJS X.Y was compatible with all versions of Go X.Y.??.
Starting with GopherJS 1.12-3 +1, we're using a new versioning schema, which separates GopherJS versions from Go versions. This is to make it clear when GopherJS tooling is updated, irrespective of the supported version of Go. The new versioning schema is simply:
v<gopherjs semver>+go<ver>
To demonstrate, GopherJS version 1.12-3 becomes v1.12.3+go1.12. If/when a breaking change is made to GopherJS, the GopherJS version may increment, regardless of whether the supported Go version increments. I.e we may have v2.0.0+go1.12. Likewise, the Go support may increment, without any breaking changes, leading to something like: v1.13.0+go1.16.