Husky creates all types of hooks even if I have only specified precommit hook in package.json

[jforjava1981]

Husky is creating all types of git hook scripts by default even if I have just specified precommit hooks in scripts tag of my package.json. Is there a way to disable and only create script which has been specified ?

relevant part of my package.json looks like this :
...

scripts:{
...
precommit : "node runeslint.js"

}

where runeslint.js is my custom node JS script file.

In my .git/hooks directory I see husky creates all types of git hook's script files apart from pre-commit. Can we disable this? if not is it possible to introduce this as a feature?

I am using husky version 0.14.3

[alexeyten]

What would you expect if you later add hook script to package.json?

[jforjava1981]

Ofcourse that would be a problem .but cant that be solved by uninstalling and installing husky again..its not that we keep adding hooks often enough.

[jforjava1981]

I think installing every type of hook by default is a bit overkill if we are never going to need many of them. Cant we have this enabled based on option rather than having it as default?

[voxpelli]

It's required for husky to be able to act on hooks that may appear after it has been installed, through eg. a team member having added it and committed it to your repo.

Requiring everyone in the team to re-sync their hook-definitions when a new hook has been added removes the assurance that everyone on the team will be running the hook configuration that you are setting up.

The usefulness outweighs the possible ugliness 🙂

[jforjava1981]

@voxpelli : Agree. However as I said its not often enough that we keep installing hooks. What I would like is the option to choose the ugliness which can be agreed at team level and team can opt in for ugliness using an option rather than being forced to have it by default.

[liweinan0423]

On some CI services it clears all un-versioned files such as node_modules on each build then checkout a specific commit. In this case the post-checkout hook will fail due to the lack of the run-node package because the node_modules folder is empty

So I'd suggest to support a .huskyrc files where user can explicitly define what hooks will be installed

[typicode]

Hi @liweinan0423,

Thanks for the feedback. By default, husky shouldn't install Git hooks on CI services. It uses https://github.com/watson/is-ci for that. Which CI is it?

You can also set HUSKY_SKIP_INSTALL=true env variable to skip husky install.

[mandarvaze]

It might be good to allow user to select which hooks she wants to install
python counterpart to husky pre-commit has such an option

[jforjava1981]

can somebody let us know if this will be added/fixed ?

[aniforprez]

Coming from backend dev to frontend I am utterly baffled how a package with the tagline "git hooks made simple" does so much non-simple magic in the background that a simple install is overly complicated and burdened with so much stuff going on. I've failed to get anything done on my system with this because it uses a different package to detect if my system is a CI system (it's obviously not) and that is throwing false positives

Please make installing hooks an actual option that you can either configure or manually trigger with options as to which hooks you need installed. This is already a resolved issue by almost every other git hooks package in other languages. Please use the extremely elegant pre-commit as reference

[voxpelli]

@aniforprez If you are so baffled by it, then why are you using it? You fail to describe the use case that causes your frustration

[aniforprez]

@voxpelli I'm NOT using it. I don't know why you're making that assumption. I TRIED using it and failed utterly. I'm ditching this in favor of just using pre-commit which, from my personal experience, is far superior of a tool with wide support.

I've also very clearly mentioned my frustration is that the tool DOESN'T INSTALL for me. It literally always skips installing the hooks in my system claiming it's running in a CI environment when it's just my Macbook Air without much fluff added to it. This is triggered because there's a package husky uses that alerts it to being in a CI environment that's throwing a false positive. That's the extent of my debugging abilities cause reading that package's source almost drove me insane trying to understand why it was giving me this issue

I'm completely baffled why installing hooks is not just an opt-in instead of the nonsensical method of doing all this magic during install. This way CI systems won't have the hooks unless you actually trigger the commands. Why this wasn't the first thought when building this package I'll never understand

I'm also very sorry I'm being so harsh but the hours I spent trying to understand and unravel this mystery is something I'll never get back and I found zero solutions to this problem

[voxpelli]

@aniforprez For most users it obviously works well and it’s unfortunate that it doesn’t for you. Some like magic, others doesn’t. This tool eg works wonders for me.

That said, you’re somewhat barking up the wrong tree here. As mentioned above this package doesn’t itself detect CI servers but uses a module for that. If that modules detects your setup as a CI environment then that’s a bigger issue than this package in itself. So I suggest filing an issue there: https://github.com/watson/ci-info And maybe even do a PR?

[aniforprez]

@voxpelli uhh I did say exactly that the package husky is using is the culprit but the point is husky itself has created problems for itself doing things in a non-standard magic way. For people who can't work with that magic or don't want it have literally no way of opting in

My point is exactly where it should be. Husky should be opting in to hooks rather than create a mess of files on the off chance of someone maybe configuring additional hooks that happens exceedingly rarely if at all. Husky should allow manual install of hooks if one has opted out or is not able to opt in at install. These are husky's faults squarely

[mandarvaze]

@aniforprez pre-commit was already suggested

For some reason, it is not in line with the philosophy of this package to make it like pre-commit. To be fair, they have all the right to choose what to support and what not to.

You are already NOT using it (Neither am I, and probably others who are asking for this support)
Voicing frustrations does not add any value, PR might. (Be prepared that it may be rejected)