# 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.

# Submitting a pull request

  1. Fork and clone the repository.
  2. Run npm ci.
  3. Create a new branch: git checkout -b my-branch-name.
  4. Make your change, add tests, and make sure the tests still pass.
  5. Commit and push to your fork and submit a pull request to the relevant branch.
  6. 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 (opens new window).
  • 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 (opens new window) 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/....
1
2
3
4
    feat(graphql): Started building the GraphQL driver
    
    - Added response parsing support
    - Added request compiling service
1
2
3
4
  • 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
1
2
3
4
5
  • chore: - commit for code maintenance pull request e.g.:
    chore(dev-deps): Updated dependencies
    
    - rollup
    - typescript
    - eslint
1
2
3
4
5
  • docs: - commit for a branch updating the documentation e.g.:
    docs(helpers): Clarified testing helper's description
1

If your commit is related to a discussion/issue on github, please link to it (opens new window) in your commit message.

If 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 (opens new window) and create a symbolic link between framework the the docs e.g.:

ln -sf /absolute/path/to/upfrontjs/framework/docs/* /absolute/path/to/upfrontjs/docs/
1

# Resources