With the new v7 way of configuring hooks, what is the point ?

[LexouDuck]

I recently updated to husky v7, and was surprised to see things not working: so I went to look at the changes, and I am rather surprised at the changes made to the way configuration of hooks is done.

I have read the two articles which are linked at the end of the README.md:

• https://blog.typicode.com/husky-git-hooks-javascript-config/
• https://blog.typicode.com/husky-git-hooks-autoinstall/

Maybe you have had different experiences, but to me, the entire point of husky is to be centrally configured from the package.json file, and to be autoinstalled whenever someone clones the repo in question (mainly, because the default hooks path, the .git/ folder, cannot be checked into the repo - or at least, that wasn't possible before git added the hooksPath setting).

The first article does seem to address my point though, near the end of it:

“Why still use husky if there’s core.hooksPath?"
Husky provides some safe guards based on previous versions feedbacks, user-friendly error messages and some additional features. It’s a balance between going full native and a bit of user-friendliness.

This answer is quite vague... Where can I learn what "safe guards" exist ? What are these "additional features" ?
This is the main reason I am launching this discussion: I believed the purpose of husky was to simplify git hooks configuration by having it follow the JS way of doing things. It seems that is isn't the case after all, so I also wish to ask: with the existence of the core.hooksPath setting and the npm prepare script, what is the purpose of husky ?

[Airkro]

I stop using husky because npm prepare: git config core.hooksPath .githooks is enough for me.

Is husky teaching me how to stop using husky...

[typicode]

If it's enough for you that's perfectly fine. Glad also if husky taught you something :)

Edit: I moved my explanation why I'm still using husky rather than git config directly here

[cncolder]

I've been stuck in husky 4 for a long time. I don't plan to upgrade unless husky changes back.

[jedwards1211]

We adopted husky in part because it's dumb to have to make a separate file for each hook when the scripts are so short. Git should implement support for a single entrypoint script for all hooks. Then that entrypoint could just spawn some JS that decides what script to run from arguments passed in by git and package.json.

[jedwards1211]

You know, Husky's value proposition had three features:

1. Automatically installing hooks for any developer who works on the project
2. Configuring the hook scripts in a single file
3. Not having to know how git hooks work internally

Number 3 was the least valuable, but it's the only thing Husky v7 retained.
So on top of making us have to waste time on migrating config (unless we want to stick with unmaintained versions), it torpedoed the two things that were most valuable for us.

ghooks retains all three features and also avoids the out-of-sync problem (because it just puts Node scripts in .git/hooks that look in your package.json to decide what to run). Switch to ghooks folks :)

[typicode]

The downside of git config ... is that it will go below package.json and modify the repo it's in.

So I'm still using husky in my projects because it prevents the following two cases:

1. It happened that users went in node_modules and run npm install on dependencies inside (for quick tests). With bare git config core.hooksPath, the root project could have its hook path modified, creating a complicated to debug issue.
2. Projects on GitHub can be downloaded as zip or tar files. If they're extracted in another Git repo, the same issue can happen.

Also there's more logging which can help people that are not familiar with Git hooks (which can be the case in Open Source projects where many people from different background can clone the project).

Hope it clarifies a bit the reasoning :)

[LexouDuck]

1. It happened that users went in node_modules and run npm install on dependencies inside (for quick tests). With bare git config core.hooksPath, the root project could have its hook path modified, creating a complicated to debug issue.
2. Projects on GitHub can be downloaded as zip or tar files. If they're extracted in another Git repo, the same issue can happen.

Ah, I see. While that has never happened to me (nor my coworkers), I can understand that one may want to tinker inside the node_modules folder manually, or simply download a repo as a .zip file.
That being said, if we use the npm prepare/core.hooksPath method, we can still mitigate this issue rather easily (for both of the cases you listed):

    "prepare": "[ -d '.git' ] && git config core.hooksPath ./.githooks",

We simply check that there is a .git folder present in the current working directory, before changing the git config.
This way, the npm prepare script will only ever change anything when it is run from the root folder of a git repository.

---

Also there's more logging which can help people that are not familiar with Git hooks (which can be the case in Open Source projects where many people from different background can clone the project).

Aye, this much is understandable. I've always used git, and I personally tend to be quite verbose with logging in my githooks scripts, so I didn't think of this. Like I said in my original post, my main issue was that your original answer in your blog article was too vague, and didn't clarify what husky's current value proposition (or goal) is.

[typicode]

[ -d '.git' ] is a good idea 👍 Since .git can also be a file in a submodule, -d could be changed to -e to catch both cases.
The downside is obviously portability. It'll probably fail on Windows.

There's also this https://typicode.github.io/husky/#/?id=command-not-found

my main issue was that your original answer in your blog article was too vague, and didn't clarify what husky's current value proposition (or goal) is.

That's a good feedback, thanks. I think at the time I wanted to have a focused article and not be too long.

I may revisit the article or write a new one :)

In the end, git config core.hooksPath can be perfectly fine for some projects/context. For example, if it's a private project and developers have agreed on using the same OS, version manager, etc...

[tran-simon]

[ -d '.git' ] doesn't work if the package is installed a git submodule, since the .git folder isn't located at the root of the package.

[ -e '.git' ] or [ $(git rev-parse --show-toplevel) == $(pwd) ] seem to work