dboreham parent
Imho pre-commit is an antipattern. It tends to break (or rather the janky things it typically runs break) but more importantly whatever needs to be run to gate commits has to be run server-side anyway (people disable precommit, it sometimes produces false negatives, so can't be relied upon). So once you're running the checks server side now you have a second problem which is that the two checks don't always produce the same result. Better to enforce checks in CI, but also provide a way for the dev to run the same check themselves, manually.
Slow feedback loops are an antipattern. Do you like waiting 5 minutes for your checks to run on a separate computer that reports to a separate interface that you then have to navigate to and inspect the error and pull it back into your dev environment to fix? It’s soo much better running locally in 20 seconds and knowing your shit will pass or exactly where the problem is
Well, I have one well-documented exception to this rule: Secret detection. You really don't want to push secrets to your repository, especially if it's hosted as public on GitHub. Those damned attackers can find the secrets in minutes after you've pushed them so you really don't have the time to catch and rotate this (unless you're able to properly attribute and rotate them from the CI... in which case, I'd love to see it).
And...that's exactly why you might want to use pre-commit. Set it up to run locally, treating the dev environment check as the first class citizen, then just run pre-commit on all files in CI.
We use that pattern for almost all our projects. Example: https://github.com/level12/coppy