- Search for existing issues. Please check to see if someone else has reported the same issue.
- Share as much information as possible. Include operating system and version, browser and version. Also, include steps to reproduce the bug.
Refer to the README.
Please use an editor with support for ESLint and EditorConfig. Configuration files for both tools are provided in the root directory of the project.
See Mozilla Foundation JavaScript Style Guide
This project is currently in transition to fully support the latest mofo-style version. At the moment it uses a modified version of .eslintrc.yaml, provided in the root directory, instead of using the file inside ./node-modules/mofo-style/.eslintrc.yaml, in order to make the transition easier and smoother.
TL;DR Run npm run lint
before pushing a commit. It will validate your JS.
lowerCamelCase
General variablesUpperCamelCase
Constructor functions- Use semantic and descriptive variables names (e.g.
colors
notclrs
orc
). Avoid abbreviations except in cases of industry wide usage (e.g.AJAX
andJSON
).
- 2 space indentation
- Class names use hypenated case (e.g.
my-class-name
)
- 2 space indentation
- Always a space after a property's colon (e.g.
display: block;
notdisplay:block;
) - End all lines with a semi-colon
- For multiple, comma-separated selectors, place each selector on it's own line
Any patch should be manually tested in as many of our supported browsers as possible. Obviously, access to all devices is rare, so just aim for the best coverage possible. At a minimum please test in all available desktop browsers.
You can run all automated tests with mocha test/*
or npm test
. If mocha is not installed globally, please use ./node_modules/mocha/bin/mocha test/*
.
Unit and Integration tests can also be run separately with npm run test:unit
and npm run test:integration
respectively.
- Try not to pollute your pull request with unintended changes – keep them simple and small. If possible, squash your commits.
- Try to share which browsers and devices your code has been tested in before submitting a pull request.
- If your PR resolves an issue, include closes #ISSUE_NUMBER in your commit message (or a synonym).
- Review
- If your PR is ready for review, another contributor will be assigned to review your PR within 1 business day
- The reviewer will comment on the PR with a final r+ or r-, along with inline comments on the code (if any)
- r-: address the comments left by the reviewer. Once you're ready to continue the review, ping the reviewer in a comment.
- r+: You code will be merged to
master