If you haven't read it, read the very important notice about the Javalib in the Javalib documentation .
The Scala.js project has a strict policy regarding coding style. This is one of the cornerstones that has allowed Scala.js to maintain a clean, consistent and maintainable codebase.
Please consult and follow our coding style guide.
This the general workflow for contributing to Scala.js.
- Make sure you have signed the Scala CLA. If not, sign it.
- You should always perform your work in its own Git branch. The branch should be given a descriptive name that explains its intent.
- When the feature or fix is completed you should open a Pull Request on GitHub.
- The Pull Request should be reviewed by other maintainers (as many as feasible/practical), among which at least one core developer. Independent contributors can also participate in the review process, and are encouraged to do so.
- After the review, you should resolve issues brought up by the reviewers as needed (amending or adding commits to address reviewers' comments), iterating until the reviewers give their thumbs up by approving the Pull Request.
- Once the code has passed review the Pull Request can be merged into the distribution.
In order for a Pull Request to be considered, it has to meet these requirements:
- Live up to the current code standard:
- Follow the coding style
- Not violate DRY.
- The Boy Scout Rule should be applied.
- Be accompanied by appropriate tests.
- Be issued from a branch other than main or master (PRs coming from
mainormasterwill not be accepted, as we've had trouble in the past with such PRs)
If not all of these requirements are met then the code should not be merged into the distribution, and need not even be reviewed.
All code contributed to the user-facing standard library (the library/
directory) should come accompanied with documentation.
Pull requests containing undocumented code will not be accepted.
Code contributed to the internals (compiler, IR, linker, JS environments, etc.) should come accompanied by internal documentation if the code is not self-explanatory, e.g., important design decisions that other maintainers should know about.
Follow these guidelines when creating public commits and writing commit messages.
If your work spans multiple local commits (for example; if you do safe point commits while working in a feature branch or work in a branch for long time doing merges/rebases etc.) then please do not commit it all but rewrite the history by squashing the commits into one commit per useful unit of change, each accompanied by a detailed commit message. For more info, see the article: Git Workflow. Additionally, every commit should be able to be used in isolation--that is, each commit must build and pass all tests.
The first line should be a descriptive sentence about what the commit is doing, written using the imperative style, e.g., "Change this.", and should not exceed 70 characters. It should be possible to fully understand what the commit does by just reading this single line. It is not ok to only list the ticket number, type "minor fix" or similar. If the commit has a corresponding ticket, include a reference to the ticket number, with the format "Fix #xxx: Change that.", as the first line. Sometimes, there is no better message than "Fix #xxx: Fix that issue.", which is redundant. In that case, and assuming that it aptly and concisely summarizes the commit in a single line, the commit message should be "Fix #xxx: Title of the ticket.".
If the commit is a small fix, the first line can be enough. Otherwise, following the single line description should be a blank line followed by details of the commit, in the form of free text, or bulleted list.