Following Conventional Commits what would be the best <type>
for commits regarding package version changes (upgrades/updates)?
E.g.: feat: Bump React version to "16.13.1"
E.g.: feat: Upgrade all dependencies
Following Conventional Commits what would be the best <type>
for commits regarding package version changes (upgrades/updates)?
E.g.: feat: Bump React version to "16.13.1"
E.g.: feat: Upgrade all dependencies
Others: commit types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends chore:, docs:, style:, refactor:, perf:, test:, and others. We also recommend improvement for commits that improve a current implementation without adding a new feature or fixing a bug. Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE, which is NOT recommended). A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.
Source: https://www.conventionalcommits.org/en/v1.0.0-beta.2/
So an ideal candidate for me would be chore: upgrade package dependencies
which must not result in any version number bump.
Be aware though that upgrading dependencies may or may not incur breaking changes which may result in a commit significantly bigger than just a package.json
update.
But as far as your app goes, it would be your job to deal with those breaking changes without changing anything for the user. So in that respect I don't think that neither feat:
nor fix:
is justified as, ideally, this commit doesn't bring any user-facing changes.
chore
anymore. It seems the best aproach for this case is using build
, like suggested in the not accepted answer. –
Hangbird Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
. External dependencies refer to libraries and tooling supporting the build system, not the application itself. –
Dodd If you use build
scope consider this option:
build(deps): bump React version to "17.0.2"
Conventional commits are based on the Angular conventional commits. Angular's CONTRIBUTING.md
states:
build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
build(deps): bump react version to "17.0.2"
–
Acidic Others: commit types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends chore:, docs:, style:, refactor:, perf:, test:, and others. We also recommend improvement for commits that improve a current implementation without adding a new feature or fixing a bug. Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE, which is NOT recommended). A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., feat(parser): add ability to parse arrays.
Source: https://www.conventionalcommits.org/en/v1.0.0-beta.2/
So an ideal candidate for me would be chore: upgrade package dependencies
which must not result in any version number bump.
Be aware though that upgrading dependencies may or may not incur breaking changes which may result in a commit significantly bigger than just a package.json
update.
But as far as your app goes, it would be your job to deal with those breaking changes without changing anything for the user. So in that respect I don't think that neither feat:
nor fix:
is justified as, ideally, this commit doesn't bring any user-facing changes.
chore
anymore. It seems the best aproach for this case is using build
, like suggested in the not accepted answer. –
Hangbird Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
. External dependencies refer to libraries and tooling supporting the build system, not the application itself. –
Dodd © 2022 - 2024 — McMap. All rights reserved.