Git Hooks with Husky
If you followed along with Chapter 2, Integrated Tooling with VS Code, you’ve adopted a cutting-edge development setup, completed with integrated linting and auto-formatting. However, your collaborators might not be so prepared. There’s nothing stopping them from submitting a pull request that violates your project’s prescribed ESLint or stylelint rules, or which will transform when you run it through Prettier. How can you enforce those rules? You could add checks to Travis CI, but then someone still has to fix the problems. Ideally, whoever introduced the problems should fix them before pushing their branch up for everyone else to see.
That’s where Husky comes in. Husky is a tool for managing Git hooks in JavaScript projects. Git hooks are scripts that Git runs before or after certain commands, such as commit or push. In the olden days, developers had to install a project’s Git hooks on their machine manually. Husky makes this much easier: when Husky is installed by npm (or yarn), it uses a post-install script[76] to install its own Git hooks, which will run whatever commands you specify for it in package.json. For developers working on your project, the process is effortless.
Setting Up Husky
Start by installing the husky package from npm:
| | $ npm install --save-dev [email protected] |
| | + [email protected] |
Then add a new husky section to the project’s package.json to specify the hooks. Start with just one, a pre-commit hook to run eslint .:
| | // package.json |
| | ... |
| » | "husky": { |
| » | "hooks": { |
| » | "pre-commit": "eslint ." |
| » | } |
| » | }, |
| | ... |
Now try committing. Use the command line so you can see the full output:
| | $ git commit -a -m ":wrench: Add pre-commit ESLint check" |
| | husky > pre-commit (node v8.12.0) |
| | [master c8bcdab] :wrench: Add pre-commit ESLint check |
| | 2 files changed, 79 insertions(+) |
Since the linter was satisfied, there was no output from the pre-commit hook and the commit went through. If there had been any errors, you would’ve seen the ESLint output and the commit would have been blocked, giving you the chance to fix the problems and try committing again.
If you’re ever in a situation where you need to skip a Git hook—for example, if you need help resolving the linter errors you’re seeing, so you want to commit to a branch you can share with your colleagues—run the Git command with the --no-verify flag.
Chaining Checks
ESLint is just one of several tools you can run to check code before allowing a commit. Any command that returns an exit code (0 to indicate success, any other value for failure) will do the trick. The test-driven-carousel project already has three other tools available to run: stylelint, Prettier, and Jest. Running all of them before every commit could become cumbersome, though. Besides, Jest is already running on the CI. So let’s stick to the linting/formatting trio.
Recall that we’ve already combined ESLint, Prettier, and stylelint in the lint script. So rather than duplicate the commands for those tools, we can run the existing script from the hook:
| | // package.json |
| | ... |
| | "husky": { |
| | "hooks": { |
| | "pre-commit": "npm run lint" |
| | } |
| | }, |
| | ... |
Give it a try:
| | $ git commit -a -m ":wrench: Add stylelint to pre-commit hook" |
| | husky > pre-commit (node v8.12.0) |
| | |
| | > [email protected] lint /Users/tburnham/code/test-driven-carousel |
| | > npm run lint:js && npm run lint:css |
| | |
| | > [email protected] lint:js /Users/tburnham/code/test-driven-carousel |
| | > eslint . && prettier-eslint --list-different **/*.js |
| | |
| | > [email protected] lint:css /Users/tburnham/code/test-driven-carousel |
| | > stylelint **/*.js |
| | |
| | [master d6fe670] :wrench: Add stylelint to pre-commit hook |
| | 1 file changed, 1 insertion(+), 1 deletion(-) |
And we’re set! With this precommit hook in place, everyone who works on this project will have a much easier time finding out whether they’re following its formatting standards. Additionally, the same lint script would work perfectly on Travis CI, if you wanted to make it mark builds as bad when those scripts fail.
In a larger project, running all of these linters against the whole source tree before every commit could become cumbersome. If you run into that problem, you should check out lint-staged,[77] a package that allows you to run linters against only the files that are part of the pending commit.
Hopefully, you’ve gotten a hang of how you can use Husky to help developers identify and fix problematic code before they share it with the world. It’s one of the simplest tools around, yet there’s a ton you can do with it. To learn more, check out the Husky docs.[78]