Others:
https://direnv.net/ -- when you cd to a directory, do things like set variables.
https://asdf-vm.com/ -- manage and use specific versions of software. Can work with direnv too!
https://pre-commit.com/ -- git hooks that I personally found easier to manage than Husky.
https://github.com/qoomon/git-conventional-commits -- enforce standard commit messages. Works with pre-commit!
I loathe pre-commit hooks. I often times just want to save work in progress or show someone what I have right now and they slow down my work or worse fail and lose my commit message and cause me to have to figure out how to disable them to continue. If you want to run checks for formatting or similar that is much better done in CI. I can get a reminder without breaking any dev workflows. Of course make fixing formatting a single command, and maybe an optional hook for those that prefer it. But when projects try to auto-install hooks it drives me crazy.
Any check that take more than 6 seconds can also go jump off a cliff as car as I'm concerned.
But I do greatly value fast fixing & feedback. Run format! (and don't print out unchanged things!) Run lint! Maybe run tests, if they're fast.
One of the constraints becomes that you are trying to make quick actionable easy to view data, and the output can become too long. We had some outside teams come in & deploy centralized & more updated lint & testing, and alas there's just multiple pages of yellow jest configuration warning as it starts, and it's just so much harder to quickly check status. These hooks need to be quick to read, as well as run. All of the hooks should run if they can, not stop on first problem.
Ideally the ci/CD system is a good fast way to see test results. Devs shouldn't even have to think about it, just commit & off board the running. I hear Facebook has very interesting systems where devs aren't even having to make commits for this, which sounds epic. Alas many ci/CD systems are doubly slow, which sucks: slow to start, slow execution speed, and most damming low caching, so they have to do a lot of from-scratch bring up that just takes a really long time versus what local dev has. Systems like nx in JS land are starting to change this more systematically, rather than being a lot of custom ci/CD tweaking.
Informational, not prescriptive! Use the tools to accelerate & guide. Right now we're all learning but tool heavy setups are for sure the way.
git commit -n|--no-verify
Just use dotenv instead.
https://asdf-vm.com/ -- manage and use specific versions of software. Can work with direnv too!
May be useful in some cases, but adds a global dependency on asdf itself.
> https://pre-commit.com/ -- git hooks that I personally found easier to manage than Husky.
Git hooks are disturbing and slow down and/or break advanced git interactions.
> https://github.com/qoomon/git-conventional-commits -- enforce standard commit messages. Works with pre-commit!
Only if you want to be so pedantic about them. I find it mostly a waste of time to enforce commit message style.
> Let some whitespace be programmable. The layout of the input influences the layout choices in the output. This means that the choices between single-line/multi-line layouts in certain situations are made by the user, not by an algorithm. This makes the implementation simpler and leaves some control to the user while still guaranteeing that the formatted code is stylistically consistent.
Coq, Agda, etc. also don't have formatters either, partly because "user-defined layout", but also partly because their syntax is just so complicated and they have smaller ecosystems
function(
arg,
arg
);
Then it also insists on aligning everything prettily. Most, but not all of it can be disabled though.
And lastly it doesn't do very well with tab indents. Most of it works perfectly, you just need to set both tab size and indent size, but then it decides to do its alignment thing and suddenly that line is all spaces, even the base indent.
Clang-format is honestly by far the worst formatter I've had the displeasure to fight. C/C++ still needs to be formatted manually
When someone commits changes to an existing file, they auto format before committing. If existing parts of the file already contain weird non standard formatting this creates distracting whitespace noise in the pull request that could have been prevented. It's a waste of time to not use standard formatting.
The answer to dirty diffs is to not make them. Every change should be intentional, and a reviewer should agree that it's important. "Reformat this block I haphazardly edited" is fine, but don't make the change bigger for no reason.