- Clone/Fork the repo.
- Install dependencies:
npm install
. - Ensure linting rules pass:
npm run lint
. - 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. If you need to pass additional arguments to standard-version
, you can use --
with the release
script.
Example:
npm run release -- --prerelease
Sometimes, you'll want manual control over the next version of the package. In these cases, you can refer to the standard-version
cli option --release-as
.
Major Release
npm run release -- --release-as major
Minor Release
npm run release -- --release-as minor
Patch Release
npm run release -- --release-as patch