Contributing
Hi there! I'm thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
Issues and PRs
If you have suggestions for how this project could be improved, or want to report a bug, open an issue! I'd love all and any contributions. If you have questions, I'd love to hear them, that might just mean that the documentation is lacking.
I'd also love PRs. If you're thinking of a large PR, I advise opening up an issue first to talk about it though! Look at the links below if you're not sure how to open a PR.
Which branch
Patch bug fixes should be sent to the latest stable branch. Bug fixes should never be sent to the main branch unless they fix features that exist only in the upcoming release.
Minor features that are fully backward compatible with the current release may be sent to the latest stable branch (release/{version}.x
).
Major new features should always be sent to the main
branch, which contains the upcoming release.
Until reaching a stable version (v1), all pull requests should start from main
and with your changes go into main
. After that main
will get merged into the release/0.x
branch.
Best practices
- The code should be self documenting. If a piece of logic might not be easy to reason by for a new contributor, consider adding a comment or two explaining the logic.
- The code should be written defensively to reduce the possible errors in the consuming applications. However, a balance should be struck to avoid overhead and developer relying too much on the library. Throwing errors are also accepted where the developer will likely make a fatal mistake.
Submitting a pull request
- Fork and clone the repository.
- Run
npm ci
. - Create a new branch:
git checkout -b my-branch-name
. - Make your change, add tests, and make sure the tests still pass.
- Commit and push to your fork and submit a pull request to the relevant branch.
- Pat your self on the back and wait for your pull request to be reviewed and merged.
Here are a few things you can do that will increase the likelihood of your pull request being accepted:
- Follow the style standards which is included in the project. Any linting errors should be shown when running
npm run lint
. - Write and update tests.
- Keep your changes as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
- Write a good commit message.
- Update the documentation if applicable.
Work in Progress pull requests are also welcome to get feedback early on, or if there is something blocking you.
Commit Message Formats
Commit messages are integral to navigating version control, be it by a human or automated tool. To attempt to standardise the messages, upfront uses conventional commit messages e.g.:
feat:
- commit for a feature pull request e.g.:
feat(collection): Add isEmpty method to the Collection class
Added isEmpty method as previously discussed on
https://github.com/....
feat(graphql): Started building the GraphQL driver
- Added response parsing support
- Added request compiling service
fix:
- commit for bug fixing pull request e.g.:
fix(query-builder): Fixed the invalid query response handling logic
Updated handler to correctly parse response and
added graceful error handling
Resolves upfrontjs/framework#99, upfrontjs/framework#100
chore:
- commit for code maintenance pull request e.g.:
chore(dev-deps): Updated dependencies
- rollup
- typescript
- eslint
docs:
- commit for a branch updating the documentation e.g.:
docs(helpers): Clarified testing helper's description
If your commit is related to a discussion/issue on GitHub, please link to it in your commit message.
If you need more guidance beyond the conventional format, you may use npm run commit
which will help build a commit message. Additional help can be found at the resources section.
Documentation
This documentation is kept alongside the source code to keep it in sync with the code it belongs to, and to allow for updating the docs in one go with code changes.
To update the docs in the context of this documentation site I advise you pull down the upfront docs repo and create a symbolic link between framework the docs e.g.:
ln -sf /absolute/path/to/upfrontjs/framework/docs/* /absolute/path/to/upfrontjs/docs/