New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: add commit hooks #632
Conversation
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
db07e74
to
96be7ee
Compare
package.json
Outdated
"preversion": "npm run rebuild", | ||
"prepare": "husky install", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
prepare
runs on publishing too. Why not postinstall
?
sidenote: husky is fairly complex. Do we need more than https://www.npmjs.com/package/pre-commit ?
(edit)
Oh, wait - pre-commit won't handle checking the message. nevermind
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went for https://github.com/toplenboren/simple-git-hooks last time I had to pick one FWIW. pre-commit
drags along a bit too much deps too be worth it imo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good. husky is also fine.
Let's address the lifecycle script choice though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you may be right about postinstall
if we want to avoid husky install
on publish--but only because we're in a workspace root. prepare
should probably be calling npm run rebuild
instead of preversion
, then.
wait, because we have allow-scripts
configured, it doesn't run automatically anyway.
anyhow, I've changed it to this:
postinstall
runshusky install
prepare
runsrebuild
, which calls therebuild
script in workspaces where it is extantpreversion
removed- add
$root = true
toallowScripts
config
96be7ee
to
d08ec8a
Compare
d08ec8a
to
2d485ca
Compare
.github/workflows/commitlint.yml
Outdated
@@ -0,0 +1,17 @@ | |||
name: Validate Commit Messages | |||
on: | |||
[pull_request] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to running it as early as possible, not only for things targeting master.
This may occasionally be annoying when doing messy experiments, but it's totally worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lol, I just reverted this. I'm not sure it is worth it, honestly. but I'll put it back.
note that it does not run on push
because, well, if you've pushed to main
it's too late anyway. maybe we need a branch protection rule (if we don't have one already) that disallows direct pushes to main
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a section to the README documenting the commit convention matching commitlint.config.js
Here's an example of the commitlint job running: https://github.com/LavaMoat/LavaMoat/actions/runs/5685783177/job/15411381654?pr=632 |
175a5ba
to
94e21e9
Compare
20bc7e1
to
429b311
Compare
- adds a pre-commit hook that runs `eslint --fix` on any JS file on the stage - adds a commit message check that verifies the commit message is in conventional commits format - adds `husky install` to workspace root `postinstall` script, to be run via `allow-scripts` - adds a `prepare` lifecycle script which runs the `rebuild` script - remove `preversion` script
429b311
to
3bc906b
Compare
This change:
eslint --fix
on any JS file on the stage.main
We will definitely want this if we want better automation of our releases. Please see these docs for more info about commitlint and how we can further configure it. I have created a configuration which adopts the conventional commits format but also relaxes some of the more pedantic default rules.