{"id":1782,"date":"2018-12-11T13:43:49","date_gmt":"2018-12-11T12:43:49","guid":{"rendered":"https:\/\/www.thecodecampus.de\/blog\/?p=1782"},"modified":"2023-12-20T19:52:16","modified_gmt":"2023-12-20T18:52:16","slug":"using-git-hooks-to-keep-your-codebase-clean","status":"publish","type":"post","link":"https:\/\/www.thecodecampus.de\/blog\/using-git-hooks-to-keep-your-codebase-clean\/","title":{"rendered":"Using git hooks to keep your codebase clean"},"content":{"rendered":"

Problem<\/h2>\n

Let’s be honest – developers tend to be lazy. Whenever you start a new project you’re probably saying to yourself that you want to do everything better this time but often times your new project becomes the same mess as your previous one. I want to introduce a neat little trick that might help your codebase to stay clean from the beginning. We’re only taking a look at how you can force all of your developers to use the same codestyle across your new angular project that was created using the angular-cli<\/a>.<\/p>\n

tl;dr;<\/h2>\n

install\u00a0husky<\/a><\/p>\n

npm i husky --save-dev<\/pre>\n
trigger the linter whenever the git postcommit<\/strong>\u00a0hook is called<\/p>\n
\"scripts\": {\r\n  \"lint\": \"ng lint\",\r\n  \"precommit\": \"npm run lint\"\r\n}<\/pre>\n
Now you’re not able to commit when your code contains linting errors.<\/p>\n
Goal<\/h2>\n
In bigger projects with a team size larger than 2-3 people you will typically encounter situations where developers have different opinions about how the applications code should look like. This is why linters became popular and are almost a standard in web application development. The angular-cli comes with a bundled linter that you can configure through the auto-generated\u00a0tslint.json<\/strong>.<\/p>\n
I discovered that even though there are global linting rules people tend to forget about them until the build server tries to build the application, fails and sends you an email about the failure. I stumbled across the husky package and figured it might solve the issues we had. In the following setup I’ll show you how exactly you can integrate this workflow into you project.<\/p>\n
Setup<\/h2>\n
install the npm package husky<\/a>. This package allows you to trigger scripts in your package.json<\/strong> whenever git hooks are executed.<\/p>\n
npm i husky --save-dev<\/pre>\n
add the following to the scripts section of your package.json<\/p>\n
\"scripts\": {\r\n  \"lint\": \"ng lint\",\r\n  \"precommit\": \"npm run lint\"\r\n}<\/pre>\n
now whenever you’re performing a git commit<\/strong>\u00a0either through the commandline or via your IDE the precommit hook will trigger and execute whatever script you defined. In our case we want to tell our linter to lint the whole codebase and search for violations of our linting rules. Since we’re dealing with an angular application that is set up using the angular-cli the command we want to run is ng lint<\/strong>.<\/p>\n
Whenever your code contains a linting error the ng lint<\/strong> command will finish with a non zero exit code and will therefore fail the git commit<\/strong> command and present an error message to you.<\/p>\n
Advanced Setup<\/h2>\n
If linting the codebase is not enough for you, you’ll might want to add a prepush\u00a0<\/strong>hook that executes unit tests and only allows the developer to push the changes if all the unit tests execute just fine. This of course requires the tests to run fast (hint: jest could you with that<\/a>).<\/p>\n
\"scripts\": {\r\n  \"test\": \"ng test\",\r\n  \"lint\": \"ng lint\",\r\n  \"precommit\": \"npm run lint\",\r\n  \"prepush\": \"npm run test\"\r\n}<\/pre>\n
To avoid the package.json<\/strong> to get bloated with tons of entries husky lets you use a separate config file. You can copy-paste all the hooks you defined in the script section of your\u00a0package.json<\/strong> into a new file called .huskyrc<\/strong><\/p>\n
\n
\/\/ .huskyrc\r\n{\r\n  \"hooks\": {\r\n    \"precommit\": \"npm test\"\r\n  }\r\n}<\/pre>\n<\/div>\n
There might be situations where you don’t want to run those hooks. You can easily bypass them using the –no-verify flag when using git commit from the commandline or ticking the designated checkbox in your IDE (IntelliJ in my case) to do that.<\/p>\n
\"disable<\/a>
disable commit hooks in IntelliJ<\/p><\/div>\n
Further Reading<\/h2>\n