Sådan tilføjes Commit Hooks til Git med Husky for at automatisere kodeopgaver

Der er mange værktøjer til at automatisere vores kodeopgaver. Vi kan kontrollere syntaksproblemer med ESLint og formatere vores kode med Prettier.

Men ikke alle på holdet vil huske at køre disse kommandoer hver gang de begår. Hvordan kan vi bruge Husky til at tilføje Git-kroge til at køre dem for os?

  • Hvad er Git Hooks?
  • Hvad er Husky?
  • Hvad skal vi bygge?
  • Trin 0: Opsætning af et nyt projekt
  • Trin 1: Installation af Husky til et projekt
  • Trin 2: Konfiguration af Husky til at køre Git kroge
  • Trin 3: Brug Husky til at formatere kode med Prettier

Hvad er Git Hooks?

Git kroge er scripts, som du kan konfigurere til at køre ved bestemte begivenheder i Git livscyklus. Disse begivenheder inkluderer forskellige faser af en forpligtelse, ligesom før en forpligtelse (pre-commit) og efter en commit (post-commit).

Disse er nyttige, fordi de tillader udviklere at køre brugerdefinerede kodeopgaver eller endda håndhæve standarder ved at automatisere andre scripts til at køre disse opgaver.

Hvad er Husky?

Husky er et værktøj, der giver os mulighed for let at kæmpe Git kroge og køre de scripts, vi ønsker på disse stadier.

Det fungerer ved at inkludere et objekt lige i vores package.jsonfil, der konfigurerer Husky til at køre de scripts, vi specificerer. Derefter håndterer Husky styring på hvilket tidspunkt i Git-livscyklussen vores scripts kører.

Hvad skal vi bygge?

Vi skal oprette et simpelt projekt, som vi kan bruge til at teste Git kroge.

Mens du skulle være i stand til at følge med på ethvert projekt, du arbejder med, vil jeg bruge Next.js som udgangspunkt for dette projekt, simpelthen for det faktum, at vi kan køre en enkelt kommando for at få et projekt startede.

En overvejelse om at følge med på dette projekt er dog, at vi bruger Prettier som et eksempel på, hvad du kan gøre med Git kroge.

Prettier er et værktøj, der automatisk vil formatere vores kode for os, som, hvis du ikke forventer, at det skal ske, kan forårsage en masse stress. Ved at følge med mig ved hjælp af Next.js-projektet kan du teste dette uden at foretage utilsigtede ændringer.

Hvad angår test af Git-kroge, begynder vi med at tilføje en simpel kommandolinieerklæring for at se Husky arbejde. Men vi tester også at tilføje Prettier, som automatisk formaterer vores kode for os.

Endelig udgav Husky på tidspunktet for dette, en v5 Alpha-version af deres Git hook-løsning. Da det stadig kun er en Alpha-version, vil vi gå videre med v4, som giver os mulighed for nemt at installere Husky med npm.

Trin 0: Sådan oprettes et nyt projekt

Som jeg nævnte, kan du virkelig følge de samme trin her med ethvert projekt, der administreres med en package.jsonfil.

Next.js er absolut overkill for denne gennemgang, men målet er at minimere trinene for at blive sat op til faktisk at arbejde med Husky.

For at komme i gang med Next.js skal du navigere til det bibliotek, du vil starte dit projekt i, og køre følgende:

yarn create next-app my-husky-project # or npx create-next-app my-husky-project 

Bemærk: Du er velkommen til at erstatte my-husky-projectdet, som du gerne vil navngive din mappe.

Dette opretter en ny mappe, opretter et nyt Next.js-projekt og installerer alle afhængigheder.

Når det er gjort, skal du navigere til den nye mappe, så skal vi være klar til at gå!

Følg med på forpligtelsen.

Trin 1: Sådan installeres Husky i et projekt

For at installere Husky kan vi bruge garn eller npm.

yarn add husky # or npm install husky 

Bemærk: hvis installation af Husky på dette tidspunkt installerer v5, betyder det, at v5 er officielt frigivet. Se den opdaterede Husky-dokumentation, eller du kan installere den nyeste v4-version ved at angive [email protected] (eller hvad den nyeste version er), når du installerer.

Når pakken er færdig med installationen, skal vi være klar til at gå med Husky.

Følg med på forpligtelsen.

Trin 2: Sådan konfigureres Husky til at køre Git kroge

Dernæst skal vi oprette Husky, så vi kan bruge den til vores Git-kroge.

Inde i vores package.jsonfil skal du oprette en ny egenskab kaldet huskymed et tomt objekt.

"husky": {},

Du kan tilføje dette virkelig hvor du vil i package.jsonfilen, men jeg vil tilføje det lige under scripts  ejendommen, så jeg lettere kan administrere dem sammen.

Inde i det vil vi tilføje en anden egenskab kaldet, hooksder også specificerer et tomt objekt:

"husky": { "hooks": {} }, 

Det er her, vi skal tilføje vores Git kroge. Husky understøtter stort set alle Git kroge defineret af Git, så vi kan være så fleksible, som vi gerne vil have inden for vores Git begivenhedsflow.

For at teste dette ud oprettede jeg en ny gren, hvor jeg bogstaveligt talt tilføjede hver Git-krog fra denne side inklusive et script, der simpelthen skriver til terminalen [Husky] event name.

Bemærk: føler ikke, at du har brug for at gøre dette, medmindre du er nysgerrig. Målet er at kunne vise dig med mit eksempel, hvordan det fungerer.

“husky”: { “hooks”: { “applypatch-msg”: “echo \”[Husky] applypatch-msg\””, “pre-applypatch”: “echo \”[Husky] pre-applypatch\””, “post-applypatch”: “echo \”[Husky] post-applypatch\””, “pre-commit”: “echo \”[Husky] pre-commit\””, 

Hvad dette vil gøre er at fortælle Husky at fortæl os på hvert eneste trin, hvor vi har lov til at tilslutte os Git!

Når jeg foretager denne ændring, kan vi straks se, at Husky fyrer nogle af vores scripts af.

These are all of the events that Git allows us to hook into that happen during the commit process.

And similarly, if I push those changes out to Github, I can see that the push process runs the pre-push hook!

You may never use most of the hooks that Husky and Git provide (we only saw a few between those two commands).

But it’s awesome to be able to see how powerful this can be, whether it’s running code that formats our code, prevents secret access keys from being committed, or really anything else that can help automate important tasks to your workflow.

We can now see that we can configure Husky by specifying the configuration and the hooks right in our package.json.

Follow along with the commit.

Note: If you want to check out my branch that includes every Git hook to test with, you can find it on Github.

Step 3: How to use Husky to format code with Prettier

Finally, for a real-world use case, we’re going to test out using Prettier to automatically format our code.

Prettier is an opinionated code formatting tool that allows you to easily clean up your code to make it look like a single person wrote it.

Why are tools like Prettier important? When working through code, especially with a team, it’s important to maintain consistency so everyone knows what to expect. It will help prevent arguing over a semi-colon in a code review, but it will also help catch syntax errors and prevent bugs.

Warning: running Prettier will automatically format all of your code. While we’re going to test this out before committing the changes, once you apply this as a Git Hook, it will automate this process.

To get started with Prettier, let’s install it with our package manager:

yarn add prettier -D # or npm install prettier --save-dev 

Note: we’re installing Prettier as a devDependency as our application doesn’t need this to run.

Next, we can add a new script in our package.json that will make it easier to run Prettier to test this out.

Inside the scripts property, add:

"lint": "prettier --check ." 

For this first test, we’re going to run it as a “check” which will allow us to see which files would change.

Run the following:

yarn lint # or npm run lint 

And once we do, we can see that Prettier is telling us that would change the files listed.

At this point, our code will remain unchanged. But if we want to run Prettier for real to make those changes, we can first add an additional script:

"format": "prettier --write ." 

And if we run that script, it will update all of those files to format the code to Prettier’s specification.

Warning: just another note, running Prettier to write the changes will make changes in your files. These are all code-style changes that shouldn’t impact how the code runs, but how the code looks. Before running format, you should save any changes by committing with Git so that you can easily revert the changes if you’re not happy with them.

You can now run the script with:

yarn format 

And we can see that Prettier updated our files!

Now the part that’s relevant to this walkthrough: we can add this as a Git hook. This way, when someone tries to commit code, Prettier is run before the code is saved. This means that we’ll always keep code consistent with Prettier’s formatting style.

Inside our Husky hooks configuration, let’s add:

"husky": { "hooks": { "pre-commit": "prettier --write . && git add -A ." } }, 

If you notice in our pre-commit hook, we’re also adding git add -A ..

When Husky runs, it simply runs the script provided. When running our Prettier command, we’re only formatting the code, but we never save those changes as part of the process. So we use git add to store all of those changes and include them in the commit.

To test this out, I reverted the changes to all of the files that were formatted before. If you’re following along with the same project, you can run:

git checkout pages 

Which will reset all of the changes in pages to the last commit.

Now, let’s try to add all of our files with Git and commit the changes.

And once we run our commit command, we can see that the Husky pre-commit hook kicks in already and formats our code!

Follow along with the commit.

What can I do next?

Use lint-staged to only run formatting on changed files

We’re using Prettier right in our pre-commit hook and specifying . which means it’s going to run on all files every time.

We can use a tool called lint-staged, which allows us to still run our Git hooks with Husky, but it will only run on files that are staged.

For instance, if we wanted to do this with Husky and Prettier, our configuration might look like:

"husky": { "hooks": { "pre-commit": "lint-staged" } }, "lint-staged": { "*": "prettier --write" }, 

As part of how lint-staged runs, it will attach the changed files to the end of our Prettier statement automatically for us.

You’ll also notice we didn't include git add. lint-staged will also add any changes to Git for us automatically.

Set up a Prettier config to customize formatting rules

Prettier is very opinionated. There are some things I personally don’t prefer and you might feel the same.

Heldigvis giver Prettier dig mulighed for at oprette en konfigurationsfil, der kan tilsidesætte nogle af disse filer for at gøre din kode, lige som du og dit team ønsker det.

Bed Prettier om at ignorere filer med .prettierignore

Du vil sandsynligvis heller ikke have, at Prettier kører på "alle tingene" (måske gør du det).

Prettier giver dig mulighed for at oprette en .prettierignore  fil lige inden i projektets rod ud for package.json, svarende til .gitignore, der giver dig mulighed for at fortælle Prettier, hvilke filer den ikke skal køre på.

Følg mig for mere Javascript, UX og andre interessante ting!

  • ? Følg mig på Twitter
  • ? Abonner på min Youtube
  • ✉️ Tilmeld dig mit nyhedsbrev
  • ? Sponsor mig