DEV Community

Git hook is the excellent alternative to Husky

Krzysztof Kaczyński on December 08, 2020

Backstory Some time ago I was asked to introduce an automatization which would check if committed files fit linter rules responsible for...

Read full post

Tom Davidson • Dec 9 '20 • Edited

husky uses githooks and just uses the convention of using like-named npm run scripts as the hook script. For example, this local repo with husky has the following pre-commit script (as does all the husky installed hooks):

.git/hooks$ cat pre-commit
#!/bin/sh
# husky

# Created by Husky v4.3.5 (https://github.com/typicode/husky#readme)

. "$(dirname "$0")/husky.sh"

husky.sh then checks for config files which package manager you're using and what not but eventually just executes the script of the same hook name you have defined. husky is ux sugar on top of git hooks.

Krzysztof Kaczyński • Dec 9 '20

Yes, but it is an additional layer of abstraction which maybe you do not need. Another difference is that Husky in version < 5 (I do not know how it will work in version 5 but for this version you have to pay unless your project is open-source) without lint-staged will, lint all files not only staged files and I think it is not that good because in my opinion if you are committing 6 files you want to run your linter only on those 6 files no whole repo (it will also make committing process much longer if your project is big)

Tom Davidson • Dec 9 '20

Seems like there are several things getting conflated. You can run your shell script in an npm run script named, 'pre-commit' and not use lint-staged at all. lint-staged and husky are two different tools.

The temporary patron license window is kinda funny but I'm glad there are experimentation with open source funding models. After the funding drive / early access 5.x also will be licensed as MIT (according to the top of the project readme). The important thing is that we do not overreact to FUD. But this is a completely different issue than 'git-hook is the new husky'.

As for the unnecessary abstraction concern. Does husky, lefthook, overcommit, etc add value over using git-hooks directly? I would say in nearly all cases yes but each team/project should prob do what works best for them. git-hooks were not designed to be part of the collaborative workflow - .git/hooks/* are not nodes in the git DAG. Using the git-hook manager abstraction to hook into git but run scripts that are in other workflow tools and part of the versioned code helps the work flow code be more manageable, visible, and consistent.

In expressions-calculator you attempt to make git hooks collaborative with:

"postinstall": "ln -s -f ../../git-hooks/pre-commit .git/hooks/pre-commit",

I understand its an opinion, but I dont think this is cleaner than husky. Also, what is this doing, forcing symlinks to scripts from a grandparent dir from outside the repo?

On one had I dig a git-hooks dir in the repo root idea. If I wanted an alternative to husky I might have a deps module that on install symlinked the scripts from git-hooks/ to .git/hooks BUT, git hooks are just hooks. Not a special classification of script, why should they have their own folder in the root? Perhaps a ci dir could have a pre-commit script that gets symlinked .... or perhaps we just use husky and be done with it.

The reason I am spending this much time replying is that the rejection of husky seems to be an over reacting to the licensing FUD which hurts us all. Rather than dog the project we should help end the funding drive early, and get an MIT GA release out.

Krzysztof Kaczyński • Dec 9 '20 • Edited

"You can run your shell script in an npm run script named, 'pre-commit'" → yes I can but then I will not have access to only staged files and husky will lint all files in your project what is probably not something what you want. Probably you can try to create a script which will pull out all staged files but then why do not use git-hooks?

"it-hooks were not designed to be part of the collaborative workflow" → I agree in 100%, but husky 5 will also usegit-hooks under the hood, so not the best argument not to use git-hooks. git-hook is the best way to control commits and ultimately perform custom operations that I know of. If you have a better idea, how can I control commits in JS projects let me know?

"I understand its an opinion, but I dont think this is cleaner than husky. Also, what is this doing, forcing symlinks to scripts from a grandparent dir from outside the repo?" → as I mentioned in my article you do not have to use symlinks there is an alternative which I will paste below:

git config core.hooksPath ./git-hooks

And that's all, paste this line into postinstall script and this will work the same as symlink which I am using in my repository.

"If I wanted an alternative to husky I might have a deps module that on install symlinked the scripts from git-hooks/ to .git/hooks BUT, git hooks are just hooks. Not a special classification of script, why should they have their own folder in the root?" →I think that code splitting is always better than keeping everything in one file. If there is a possibility to move those hooks into a separated folder which will keep only those git-hooks rather than put everything into package.json than I think this is the way to go.

"The reason I am spending this much time replying is that the rejection of husky seems to be an over reacting to the licensing FUD which hurts us all" → I didn't say: "Do not use husky it is bad". I show an alternative to husky. I think many people don't know about the existence of git-hooks because husky + lint-staged is always the first result in the search engine if you are looking for information on controlling commits in JavaScript projects, so I wanted to shear my experience with git-hooks and show an alternative for this duo.

Isaac Hagoel • Dec 9 '20

I think the whole point of using husky is for anyone who clones the repo to have the hooks auto created (and stay up to date with whatever is confgured in package.json) without having to take the extra steps of creating links/scripts under .git.

Krzysztof Kaczyński • Dec 9 '20 • Edited

It works the same for git-hooks after you clone the repo and run npm install your hooks will be ready for you. You can check this repository for example: git-hooks-example. After you clone this repo and run npm install and try to commit sth which doesn't fit my linter rules you will get an error if linter won't be able to auto-fix errors

Check my custom git-hooks directory and npm postinstall in packages.json.

Isaac Hagoel • Dec 9 '20

Very nice! I didn't know you could do that

Carsten Führmann • Dec 11 '20 • Edited

Husky is a convenient way of auto-adding Git hooks during npm install or yarn install. But more importantly, it is a way of providing platform independence for hook scripts. This blog post uses #!/bin/bash. But what if the developer does not have sh? (As is the case for most Windows users.) By contrast, we do have the guarantee that every user of husky has NodeJs.

Krzysztof Kaczyński • Dec 11 '20 • Edited

This is * #!/bin/sh not #!/bin/bash. I added an example to this blog post. You can download it and check that this will work on Windows too: git-hooks-example

Carsten Führmann • Dec 12 '20

I didn't claim it was bash. The Windows command line interpreter definitely cannot run arbitrary sh scripts, which are a Unix standard. Let alone certain basic commands - for example cp is for copying files on Unixoids, but copy must be used on Windows. It's interesting that your script runs on Windows. I see two possible explanations: Either your script is so parsimonious that its syntax is valid both in sh and on Windows. Or somehow Git, or your Git installation, brings sh with it. It would be interesting to figure out if the second explanation is true. It would also be interesting to know if, for example, you could use the cp command on Windows from a sh script like yours above.

Zenobius Jiricek • Sep 30 '22

you can if you install winbash, which is different from msysgit bash in that winbash actually treats windows paths as windows paths, where as msysgit bash mutates them to some virtual-path-that-like-linux-but-not-really-linux.

Manav Misra • Dec 8 '20

This is good info...but, it sure is simple to do: npx mrm lint-staged

Krzysztof Kaczyński • Dec 8 '20

Hmm but if I use this npx mrm lint-staged, then I have to remember to run this script every time before I commit any changes. git-hoos will do it automatically. Correct me if I am wrong

Manav Misra • Dec 8 '20

Well, not necessarily. npx mrm lint-staged will add that to 'package.json' so it's all included with npm i. I use it for 'student repos' in my classes.
As you say though, we are adding dependencies. So, maybe convenience for some additional package.
So, it adds something like this one.
If it's 'new project' - not 'template repo,' then, yes, you add it manually each time.

Krzysztof Kaczyński • Dec 8 '20 • Edited

Yes, but now you are adding husky and lint-staged and this article is about that maybe you do not need it because there is actually no so much work to set up git hooks in my opinion.

This solution with husky and lint-staged was my first attempt to solve this task. I wrote about that in Backstory section

Tom • Dec 27 '20

This is great as it brings awareness of the native git functionality around commit hooks. Love it 🤓

It might be worth checking this: it looks like you aren't checking for extensions, just end of strings with your TS and SCSS file grep (/ts$ vs /\.ts$/). Thus you could have commit hooks failing because a file called "starts" or "boots" for example would be linted and likely fail if there's any non-JS code in there.

Krzysztof Kaczyński • Dec 27 '20

I am glad to hear that 😃.

You are right I should look for .ts$ (For grep you do not have to escape the . character 😉)

Lorenzo • Dec 12 '20

As someone else already said, husky uses git-hooks under the hood.
The main point is that when working in a team husky let you share the pre-commit hook with your team since it's in the repo,v defined in the package.json.
Going with your solution will require to share an additional file. I've used that in the past but I can assure you that not every team member will set up the pre-commit hook manually.
With husky it's automatic.

Krzysztof Kaczyński • Dec 12 '20

Lorenzo, please check an example which I added to this article. The team member only has to run npm install this will trigger npm postisntall which will set up git-gooks automatically. I think that every developer after downloading JavaScript project with npm will run npm install before he starts to work with this code

Lorenzo • Dec 12 '20

Sorry, i missed that part 😅 (i read the post and replied with my little son climbing on me)

Christian Kozalla • Dec 8 '20

Thank you for this remarkable post about git-hooks!

I was looking for a tool to run a script to generate a new site map on my blogs repo every time I added a new post (new md-file in posts directory). I stumbled upon git-hooks then, but didn't dive into the shell scripting.. With your article I am going to set it up this week 😄

Krzysztof Kaczyński • Dec 8 '20

I'm glad to hear that 😄

Viktor Zozuliak • Dec 14 '20

There is one limitation which comes with this solution - all git hooks become source-controlled.

The whole idea having git-hooks out of source control under .git/hooks folder is to give flexibility for users/tools to install their own hooks without interfering with other repository contributors.

While this is definitely a corner case and in most cases users don't install their own hooks and don't use dev tools which do so, still it can be an issue. And Husky solution doesn't have this limitation.

Ålex • Dec 9 '20 • Edited

"Git hook is the new Husky" makes it sound like Husky isn't git hook under the hood and no mention of that either in your article. Hmm.. JS is the new React when? I'm sure that would speed some apps up "about twice".

Dorival Pedroso • Feb 9 '21

Good idea!

I also run tsc to check my TypeScript code. Here you go my git pre-commit hook (based on yours; thanks):

#!/bin/sh

staged_files=$(git diff --cached --diff-filter=d --name-only | grep  -E '\.(js|jsx|ts|tsx)$')

# skip if there are no js or ts files
if [ -z "$staged_files" ]; then
    exit 0
fi

# run type-check
yarn run --silent tsc
tsc_exit_code=$?

# check the tsc exit code
if [ $tsc_exit_code -ne 0 ]; then
    echo "🥵 tsc failed"
    exit 1
else
    echo "👍 tsc"
fi

# run linter on staged files => save exit code for later
yarn run --silent eslint $staged_files --quiet --fix
linter_exit_code=$?

# add files auto-fixed by the linter
git add $staged_files

# check linter exit code
if [ $linter_exit_code -ne 0 ]; then
    echo "🥵 lint failed"
    exit 1
else
    echo "👍 lint"
fi

# return 0-exit code
echo "🎉 all good to go"
exit 0

Zenobius Jiricek • Sep 30 '22 • Edited

I think this will fail if you're using isolatedModules

Jon Randy 🎖️ • Dec 9 '20 • Edited

So, going straight through Githooks instead of using Githooks through Husky is faster! Mind blown 😂

Federico "Edo" Granata • Dec 16 '20

Well git hook can't be the new husky because husky use git hooks ... (BTW After the early access, husky v5 will be MIT again.)

Husky is a simple way to have the hooks under versioning and shared between all the devs ... sure you can reinvente the wheel again but the whole post looks like a big misunderstanding of husky.

There's nothing wrong in manually create your link to emulate what husky already does but "Git hook SURELY ISN'T the new Husky"

Eugene Samonenko • Dec 11 '20

If you can't sponsor Husky, that's okay, husky v4 is free to use in any project. During the early access, v4 will continue to receive maintenance updates.

After the early access, husky v5 will be MIT again.