Why husky doesn't autoinstall anymore
Another change with the new husky is that it doesn’t autoinstall Git hooks anymore.
Instead, the new recommended way is to have a
prepare* script in your
"prepare": "husky install"
Let’s see why.
(*) There’s an exception for Yarn 2 though, see docs.
Package managers best practices
For years, package managers have discouraged the use of
postinstall for anything else than compilation.
By removing autoinstall, the new husky is a better citizen and also the first version to support Yarn 2 zero-installs (before, it needed to be unplugged).
From npm docs: best practices
“You should almost never have to explicitly set a preinstall or install script. If you are doing this, please consider if there is another option. The only valid use of install or preinstall scripts is for compilation”
From Yarn 2 docs: a note about postinstall
“Postinstall scripts have very real consequences for your users. […] the gist is that we don’t think postinstall scripts are a viable solution”
Recent issues with autoinstall
With recent package managers improvements (npm 7, Yarn 2), users were starting to have complex to debug issues with husky 4 autoinstall.
It became less reliable: to provide faster installs, package managers use caching (which is very good).
As a consequence, husky 4
postinstall script doesn’t always run now.
For example, if for some reasons husky 4 failed to install the first time, re-running
npm install won’t work due to the cache.
There’s no more output: package managers now hide
There’s no more confirmation that hooks have been installed or info messages to help users debug problems.
This might not seem much, but in Open Source projects, users with varying experience may clone a project. Having some kind of info message is therefore important. Especially for a tool with a big side effect (changing Git hooks) like husky.
These behaviors (one-time postinstall, no output) make sense if you consider that
postinstall should only be used for compilation.
Husky drops autoinstall to:
- follow package managers best practices and evolutions
- be more reliable and predictable
- keep user-friendly messages for people with varying experience