An npm module named husky destructively added pre- and post-commit hooks to my dotfiles repo (literally ~/.git!). Or maybe some other module told it to do that. I never asked for that. I don't understand why the JavaScript tool ecosystem is like this!
please don't "distrupt" my dotfiles, tech industry
Exciting update: it destructively installed 18 different git hooks.
It added this line to them:
cd "Library/Caches/Yarn/v1/.tmp/05ed5008bcb53e627e45ebc9b505a305.72b166a921bc8f83926da736ee9fef7a69a34d71.prepare"
A bizarre hard-coded path. I only noticed this because for some reason that path is gone now, so it was failing.
cd "Library/Caches/Yarn/v1/.tmp/05ed5008bcb53e627e45ebc9b505a305.72b166a921bc8f83926da736ee9fef7a69a34d71.prepare"
A bizarre hard-coded path. I only noticed this because for some reason that path is gone now, so it was failing.
Maybe nvm is the one who did this? It's impossible for me to tell from these files. Whatever tool decided to add 18 git hooks to a repo without asking didn't even have the courtesy to leave a comment unambiguously naming itself.
Does anyone know what tool actually created these hooks? A few packages are implicated. Here's one of the files. The hook files are all the same other than a few points where they mention their own names. 
Well there's your culprit, I guess: ->
Now I'm curious about how widespread this is. Go into your projects that use npm and do this: `grep -r husky .git/hooks`. Has it added hooks to your repo? If so, did you know that it did that? (Half the npm universe seems to depend on husky transitively, so you probably have it.)
This is a great microcosm of how programming tools have changed. In the mid 2000s, I wrote my own script to install all of our Python deps. The packages were committed directly to the hg repo. It was more work, but I knew exactly what was happening so there were rarely surprises.
I diagnosed and reproduced this. Installing husky as a dev dependency causes it. If you ever have a package.json with a dev dependency on husky, but you're not inside a git repo, husky will search through parent dirs until it finds one and add hooks to it, even if it's ~/.git.
I'd never heard of husky, though, so I didn't add it as a dev dep. And I don't know why I'd ever do `npm install` in someone else's project without a .git present. So the actual situation that caused husky to mutate my dotfiles repo probably involved more complexities.
I feel bad for newer programmers who have to work with this stuff. If I didn't know about git hooks and Unix, I probably would've just had a bunch of errors show up every time I committed (which was the symptom that led me to find those hooks).
When you see a new developer's machine spewing errors about "Library/Caches/Yarn/v1/.tmp/05ed5008bcb53e627e45ebc9b505a305.72b166a921bc8f83926da736ee9fef7a69a34d71.prepare" whenever they commit, please help them, I guess? I don't know what the moral is here.
I don't know why I'm still thinking about this, but here's a shell command that reproduces the behavior:
(mkdir tmp && cd tmp && git init && mkdir tmp2 && cd tmp2 && ls ../.git/hooks && echo '{"devDependencies": {"husky": "1.1.4"}}' > package.json && npm i && ls ../.git/hooks)
(mkdir tmp && cd tmp && git init && mkdir tmp2 && cd tmp2 && ls ../.git/hooks && echo '{"devDependencies": {"husky": "1.1.4"}}' > package.json && npm i && ls ../.git/hooks)
It will list the hooks in ./tmp/.git/hooks, then install husky into ./tmp/tmp2, then list the hooks again so you can see that they were mutated. Imagine that ./tmp is your home directory and ./tmp/tmp2 is a package from a tarball or some other source without a .git.
People are now replying to explain that this is my fault for using husky and not knowing what it does. I've never used husky. I learned about husky because I noticed that it had installed these git hooks.
