Husky errors when attempting to install published package from npm

[joejordan]

System: Windows 10
NPM version: v8.19.2
Node version: v16.13.2

I used this template as the base for a library I published to npm recently. Everything seemed to be okay until I attempted to install the published the npm package into a blank project. I received an error caused by Husky upon attempting to install the package, as follows:

npm ERR! code 1
npm ERR! path D:\dev\projects\demo-import\node_modules\crambit
npm ERR! command failed
npm ERR! command C:\WINDOWS\system32\cmd.exe /d /s /c husky install
npm ERR! 'husky' is not recognized as an internal or external command,
npm ERR! operable program or batch file.

In my package.json, I blanked the scripts "postinstall" entry and republished the package. I was then able to install from npm without issue.

I'm not too familiar with what exactly husky is supposed to be doing here. Any suggestions for a fix besides the above workaround?

[PaulRBerg]

Hi @joejordan, this is a known issue with Husky and the latest Yarn. It's explained in the docs:

if your package is not private and you're publishing it on a registry like npmjs.com, you need to disable postinstall script using pinst. Otherwise, postinstall will run when someone installs your package and result in an error.

You do want to keep the postinstall script if you want to automatically get husky-powered Git hooks immediately after cloning your repo. However, if you don't care much about this, feel free to remove Husky completely. If you do that, you can remove the postinstall script, too.

[PaulRBerg]

Update: this template no longer uses Husky and Conventional Commits, so the postinstall trick with pinst is no longer necessary.

be349da

[ahmedali8]

Hi @PaulRBerg, what are the main reasons you removed Husky, commitlint, and lint staged from this template and across all your templates?

[PaulRBerg]

I just ended up passing the -n flag so often that I did not see the value anymore.

• Long commit times locally
• Committing didn't work when offline (awful on airplanes)
• Error-prone setup (having to maintain scripts in package.json lest the published npm package would break)
• CI achieves the same purpose in a more ergonomic way

[ahmedali8]

Thanks for the response, I also use -n flag 99% of the time.