Add commitizen to package templates #418
Conversation
🦋 Changeset detectedLatest commit: 905055c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
package.json
Outdated
| @@ -62,6 +62,7 @@ | |||
| "babel-plugin-macros": "^3.0.1", | |||
| "babel-plugin-module-resolver": "^4.1.0", | |||
| "chalk": "^4.1.0", | |||
| "commitizen": "^4.2.3", | |||
There was a problem hiding this comment.
I'm not keen on bundling commitizen into skuba itself while it has high-severity security vulnerabilities that have gone unpatched for months. If we're sure this is still the best tool for the job (what does it do besides present ~2 prompts to the user?) I'd place it in the template package.json.
There was a problem hiding this comment.
Cool, can move it to templates then 👍
There was a problem hiding this comment.
I guess sec is less of a concern for dev deps on packages
| "lint": "skuba lint", | ||
| "release": "yarn build && skuba release", | ||
| "test": "skuba test --coverage", | ||
| "test:watch": "skuba test --watch" | ||
| }, | ||
| "config": { |
There was a problem hiding this comment.
- I believe we can/should do the same to the
oss-npm-packagetemplate. - Should we add a section to the relevant template READMEs?
There was a problem hiding this comment.
Ok, I was just not sure about the oss, just because you could go either way about it and implement changesets for example
There was a problem hiding this comment.
👍 It's definitely easier to get Changesets going in oss, but it should be fine to include this out of the box since the template defaults to using Semantic Release anyway.
|
|
||
| In order to facilitate the alignment with semantic release commit naming convention you can use `yarn commit` command. The script will take you through a range of questions, in the end of which you will have a correct commit name and description for semantic release to pick it up. | ||
|
|
||
| However, if you are using _squash and merge_ commits you will need to ensure the convention is preserved upon merging the pull request on Github by ensuring title and description are still populated with necesary details and follow the convention. |
There was a problem hiding this comment.
Should this go in its own section under Release? Something like:
## Release
...
### Commit messages
Here!
### Releasing latest
...There was a problem hiding this comment.
As you wish, I think it makes sense 👌
72636c
changed the title
We use semantic release as a primary release mechanism for private packages, and many teams and individuals still struggle from not being able to construct semantic commit names, so adding
commitscript to assist with on-boarding.