We love contributors! Pact-js is maintained and contrbuted to by developers just like you.
We have a development channel in the pact-foundation slack (
Before raising an issue, make sure you have checked the open and closed issues to see if an answer is provided there. There may also be an answer to your question on stackoverflow.
Please provide the following information with your issue to enable us to respond as quickly as possible.
- The relevant versions of the packages you are using.
- The steps to recreate your issue.
- An executable code example where possible. You can fork this repository and use one of the examples to quickly recreate your issue.
If you're not sure where to start, look for the help wanted
label in our issue tracker. If you have an idea that you think would be great, come and chat to us on slack in the
#pact-js channel, or open a feature request issue.
Awesome! We have some guidelines here that will help your PR be accepted:
Pact JS uses the Conventional Changelog commit message conventions. Please ensure you follow the guidelines, as they help us automate our release process.
You can take a look at the git history (
git log) to get the gist of it.
If you have questions, feel free to reach out in
#pact-js in our slack
If you'd like to get some CLI assistance, getting setup is easy:
git cz to commit and commitizen will guide you.
Commit messages with
feat prefixes will appear in the release notes.
These communicate changes that users may want to know about.
feat:messages appear under "New Features", and trigger minor version bumps.
fix:messages appear under "Fixes and improvements", and trigger patch version bumps.
If your commit message introduces a breaking change, please include a footer that starts with
For more information, please see the Conventional Changelog
(Also, if you are committing breaking changes, you may want to check with the other maintainers on slack first).
fix include bug fixes and dependency bumps that users of pact-js may want to know about.
feat include new features and substantial modifications to existing features.
Examples of things that we'd prefer not to appear in the release notes include documentation updates,
modified or new examples, refactorings, new tests, etc. We usually use one of
test as appropriate.
The recommended approach is to configure Prettier to format on save in your editor 👌. If not, don't worry, our lint step will catch it.
- Please write tests for any changes
- Please follow existing code style and conventions
- Please separate unrelated changes into multiple pull requests
- For bigger changes, make sure you start a discussion first by creating an issue and explaining the intended change