- Clone/Fork the repo
- Install dependencies:
npm install
- Ensure tests pass:
npm test
- Make changes and then make sure the tests still pass
- Push your branch/fork and submit a PR
- Assign a sparkboxer to review your PR
We use Conventional Commits and Standard Version to automate versioning of this package. Commit messages must be prefixed with a valid commit type and the commit type cannot be prefixed with any additional text.
Supported commit types include feat
, fix
, docs
, style
, refactor
, and test
.
Valid example:
feat: add new linting rule for ...
Invalid examples:
feature: add new linting rule for ...
:sparkles: feat: add new linting rule for ...
ℹ️ See the Conventional Commits page for further details on available commit types and how to handle breaking changes.
When making a change that requires a new version to be published, you'll want to run the release task before merging to master.
$ npm run release
After running this command, you'll get a preview of what the next tagged version would be. If you proceed, the release script will:
- Use all commit messages since the latest version tag to determine the correct new version
- Increment the version in package.json and package-lock.json
- Create a tagged commit with the new version
- Push your branch (and new tag) to the remote
After your branch is merged, CI will take care of publishing to the npm registry.
ℹ️ See the Standard Version documentation for details on how to control versioning behavior.
Sometimes, you'll want manual control over the next version of the package. In these case, you can use the special --major
, --minor
, and --patch
flags.
Major Release
npm run release -- --major
Minor Release
npm run release -- --minor
Patch Release
npm run release -- --patch