Help us to make this project better by contributing. Whether it's new features, bug fixes, or simply improving documentation, your contributions are welcome. Please start with logging a github issue or submit a pull request.
Before you contribute, please review these guidelines to help ensure a smooth process for everyone.
Thanks.
- Please browse our existing issues (present in the issues tab of the repository main page) before logging new issues.
- Check that the issue has not already been fixed in the
mainbranch. - Open an issue with a descriptive title and a summary.
- Please be as clear and explicit as you can in your description of the problem.
- Please state the version you are using in the description.
- Include any relevant code in the issue summary.
- Read how to properly contribute to open source projects on Github.
- Fork the project (if you are not part of the developer team).
- Create a new branch for your changes. Please name your branch in the following format:
<type>/<short-description>. Where<type>can befeature,fix,docs,style,refactor,perf,test,build,ci. The<short-description>should be a short summary of the changes you made. - Make sure your code is well-formatted and follows the project's coding style.
- Add tests for any new functionality.
- Make sure all tests pass before submitting your pull request.
- Write good commit messages based on the rules below.
- Use the same coding conventions as the rest of the project.
- Commit locally and push to your fork until you are happy with your contribution.
- Make sure to add tests and verify all the tests are passing when merging upstream.
- Don't bother adding an entry to the Changelog because it should be automatic generated based on the Conventional Commits.
- Please add your name to the CONTRIBUTORS.md file. Adding your name to the CONTRIBUTORS.md file signifies agreement to all rights and reservations provided by the License.
- Squash related commits together.
- Open a pull request.
- Write a extensive description of all the changes made on this Pull Request using the DEFAULT_PR_MESSAGE.md as template.
- The pull request will be reviewed by the community and merged by the project committers.
We use semantic commits to keep a clear and organized commit history. A semantic commit message has the following format:
<type>!(<scope>): <subject>
<body>
<footer>
The first line cannot be longer than 70 characters, the second line is always blank and other lines should be wrapped at 80 characters. The type and scope should always be lowercase as shown below.
<type>: The type of the commit. Can be one of the following:- ✨
feat: A new feature for the user, not a new feature for build script - 🐛
fix: A bug fix for the user, not a fix to a build script - 📝
docs: Documentation - 🎨
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc; no production code change) - ♻️
refactor: A code change that neither fixes a bug nor adds a feature (example scopes: renaming a variable) - 🚀
perf: A code change that improves performance - ✔️
test: Adding missing tests or correcting existing tests; no production code change - 🔨
build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) - 💚
ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) - 🚿
chore: Updating grunt tasks, tool changes, configuration changes, and changes to things that do not actually go into production
- ✨
!: If we add an exclamation mark after the type, we have a breaking change and will result in a SemVer major and it should be detailed at the<footer>(optional).<scope>: The scope of the commit, should be the name of the component that was changed (optional).<subject>: A short description of the changes made in the commit.
- uses the imperative, present tense: “change” not “changed” nor “changes”
- includes motivation for the change and contrasts with previous behavior
Referencing issues #
Closed issues should be listed on a separate line in the footer prefixed with "Closes" keyword like this:
Closes #234
or in the case of multiple issues:
Closes #123, #245, #992
Breaking changes #
All breaking changes have to be mentioned in footer with the description of the change, justification and migration notes.
BREAKING CHANGE:
`port-runner` command line option has changed to `runner-port`, so that it is
consistent with the configuration file syntax.
To migrate your project, change all the commands, where you use `--port-runner`
to `--runner-port`.
Here is an example of a semantic commit message:
feat(header): Add new feature to header component
Long description can be found here, but it is not obligatory.
Tasks #1120, #1121
Other example:
fix(middleware): ensure Range headers adhere more closely to RFC 2616
Add one new dependency, use `range-parser` (Express dependency) to compute range. It is more well-tested in the wild.
Fixes #2310
Please make sure your commit messages adhere to this format. The format of this commits are based on this gist and this article.
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
Please make sure to follow these 7 rules when writing your commit messages.
This rules are based on the artle How to Write a Git Commit Message.
We use Github Changelog Generator to generate automatically the file Changelog.
We have a Code of Conduct, please make sure you read and abide by it.
Thank you for contributing to this project!