preinstall?

[conartist6]

I'm curious about a design choice: the use of the prepare hook instead of the preinstall hook to set up husky? Why was prepare chosen?

I have a use case that has a rather nasty conflict with prepare: I'm working on tools that would allow git repositories to effectively serve as decentralized packages. This capability already sort of exists, but to date it has mostly been powered by the prepare hook. I dislike that, as it means that such decentralized packages always install all their devDependencies, and those devDependencies become security liabilities as well when they are used to output the real package code. You can't know in advance (not to a certainty at least) exactly what code the package will end up containing.

For that reason I have created tooling that permits repos to be used as packages without use of the prepare hook, but husky is one of the last tools I use that still needs it. It looks to me like there would be no problem with changing "prepare": "husky install" to "preinstall": "husky install", and of course such a change would require no official support, but I'm just wondering what the official thinking about this might be?

[typicode]

See #884

I think preinstall would fail since husky is not yet installed. If you publish a package with postinstall it will run for users installing your package (not something that is wished for husky).

[conartist6]

I think I'll have to come up with my own approach then. It won't be quite as slick, but I think I should be able to just check in everything that belongs in a hooks directory, and since I mainly use the precommit hook I can just have CI bother the user (to configure git's core.hooksDir) if it seems that precommit actions were not performed.