Как да добавите ангажиращи куки към Git с Husky за автоматизиране на кодови задачи

Има много инструменти за автоматизиране на нашите кодови задачи. Можем да проверим за проблеми със синтаксиса с ESLint и да форматираме кода си с Prettier.

Но не всеки от екипа ще запомни да изпълнява тези команди всеки път, когато се ангажира. Как можем да използваме Husky, за да добавим Git куки, за да ги пуснем за нас?

  • Какво представляват Git Hooks?
  • Какво е хъски?
  • Какво ще строим?
  • Стъпка 0: Създаване на нов проект
  • Стъпка 1: Инсталиране на Husky към проект
  • Стъпка 2: Конфигуриране на Husky да изпълнява Git куки
  • Стъпка 3: Използване на Husky за форматиране на код с Prettier

Какво представляват Git Hooks?

Git hooks са скриптове, които можете да настроите да се изпълняват при определени събития в жизнения цикъл на Git. Тези събития включват различни етапи на фиксиране, като преди фиксиране (предварително ангажиране) и след фиксиране (след фиксиране).

Те са полезни, тъй като позволяват на разработчиците да изпълняват персонализирани кодови задачи или дори да налагат стандарти чрез автоматизиране на други скриптове за изпълнение на тези задачи.

Какво е хъски?

Husky е инструмент, който ни позволява лесно да разбъркваме Git куки и да изпълняваме скриптовете, които искаме на тези етапи.

Той работи, като включва обект точно в нашия package.jsonфайл, който конфигурира Husky да изпълнява скриптовете, които посочваме. След това Husky се справя с управлението, в кой момент от жизнения цикъл на Git ще работят нашите скриптове.

Какво ще строим?

Ще създадем прост проект, който можем да използваме за тестване на Git куки.

Въпреки че трябва да можете да следвате заедно с всеки проект, с който работите, аз ще използвам Next.js като отправна точка за този проект, просто заради факта, че можем да изпълним една команда, за да получим проект започна.

Едно от съображенията за последващо заедно с този проект е, че ще използваме Prettier като пример за това какво можете да направите с Git hooks.

Prettier е инструмент, който автоматично ще форматира нашия код за нас, което, ако не очаквате това да се случи, може да предизвика много стрес. Следвайки заедно с мен използването на проекта Next.js ще ви позволи да тествате това, без да правите неволни промени.

Що се отнася до тестването на Git hooks, ще започнем с добавяне на прост израз на командния ред, за да видим как Husky работи. Но ще изпробваме и добавянето на Prettier, което автоматично ще форматира нашия код вместо нас.

И накрая, по време на писането на това, Husky пусна v5 Alpha версия на тяхното решение Git hook. Като се има предвид, че все още е само алфа версия, ще продължим напред с v4, който ни позволява лесно да инсталираме Husky с npm.

Стъпка 0: Как да настроите нов проект

Както споменах, тук наистина можете да следвате същите стъпки с всеки проект, който се управлява с package.jsonфайл.

Next.js е абсолютно преувеличен за това ръководство, но целта е да се сведат до минимум стъпките за настройване, които действително да работят с Husky.

За да започнете с Next.js, отидете до директорията, в която искате да стартирате проекта си, и изпълнете следното:

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

Забележка: Чувствайте се свободни да замените my-husky-projectкаквото искате да назовете вашата директория.

Това ще създаде нова папка, ще създаде нов проект Next.js и ще инсталира всички зависимости.

След като приключи, отидете до тази нова папка и трябва да сме готови!

Следвайте заедно с фиксирането.

Стъпка 1: Как да инсталирате Husky към проект

За да инсталираме Husky, можем да използваме прежда или npm.

yarn add husky # or npm install husky 

Забележка: ако инсталирането на Husky в този момент инсталира v5, това означава, че v5 е официално пуснат. Моля, вижте актуализираната документация на Husky или можете да инсталирате най-новата версия v4, като посочите [email protected] (или каквато и да е последната версия) при инсталиране.

След като пакетът приключи с инсталирането, трябва да сме готови да тръгнем с Husky.

Следвайте заедно с фиксирането.

Стъпка 2: Как да конфигурирам Husky да изпълнява Git куки

След това ще настроим Husky, за да можем да го използваме за нашите Git куки.

Вътре в нашия package.jsonфайл създайте ново свойство, наречено huskyс празен обект.

"husky": {},

Можете да добавите това наистина, където искате във package.jsonфайла, но аз ще го добавя точно под scripts  имота, за да мога по-лесно да ги управлявам заедно.

Вътре в това искаме да добавим друго свойство, наречено hooksсъщо, което посочва празен обект:

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

Тук ще добавим нашите Git куки. Husky поддържа почти всички Git куки, дефинирани от Git, така че можем да бъдем толкова гъвкави, колкото бихме искали в рамките на нашия Git поток от събития.

За да тествам това, създадох нов клон, където буквално добавих всяка Git кука от тази страница, включително скрипт, който просто пише в терминала [Husky] event name.

Забележка: не чувствайте, че трябва да направите това, освен ако не сте любопитни. Целта е да можете да ви покажа с моя пример как работи.

“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\””, 

Това, което ще направим, е да кажем на Хъски, че на всеки един етап, когато ни е позволено да се присъединим към Git, ни кажете!

Когато извърша тази промяна, веднага можем да видим, че Хъски изстрелва някои от нашите скриптове.

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.

Luckily, Prettier allows you to set up a configuration file that can override some of those files to make your code just the way you and your team want it.

Tell Prettier to ignore files with .prettierignore

You also probably don’t want Prettier running on “all the things” (maybe you do).

Prettier allows you to set up a .prettierignore  file right inside of the root of the project next to package.json, similar to .gitignore, that allows you to tell Prettier what files it should not run on.

Follow me for more Javascript, UX, and other interesting things!

  • ? Follow Me On Twitter
  • ? Subscribe To My Youtube
  • ✉️ Sign Up For My Newsletter
  • ? Sponsor Me