Раньше автоматизация git-хуков была зарезервирована для разработчиков.
В TalkRise мы постоянно пишем образцы проектов React, Angular и Node. Наши проекты собраны и протестированы, и мы твердо убеждены в важности автоматизации этих процессов.
Мы не хотим, чтобы мы сами или наши студенты могли коммитить код с плохим стилем или отправлять код, который не проходит тесты. Конечно, вы всегда можете сделать фиксацию WIP (work-in-progress), но когда вы пишете готовые к производству приложения с автоматизированными процессами развертывания, очень важно выявлять потенциальные ошибки до того, как они будут выпущены в мир.
Если вы Rubyist, вам давно нравятся такие инструменты, как overcommit; однако в мире JavaScript я так и не нашел отличного решения, кроме стандартного bash
скрипта.
Представляем хаски
Первоначально опубликованный в 2014 году, Husky имеет более 20 тысяч загрузок в день npm и является отличным способом использования существующих технологий для использования git pre-commit и pre-push hooks. На мой взгляд, что такого удивительного в Husky, так это то, что он вписывается в ваш обычный рабочий процесс разработки. Я уже использую сценарии npm для запуска сборки моего приложения React, поэтому за несколько шагов я могу убедиться, что мой код проверен и протестирован, прежде чем отправлять его.
Давайте рассмотрим пример использования Husky. Все, что нам нужно сделать, это установить npm (yarn).
yarn add husky --dev
Далее добавим несколько скриптов в наш package.json.
... "scripts": { "build": "node_modules/.bin/webpack", "precommit": "node_modules/.bin/eslint src", "prepush": "node_modules/.bin/jest", "start": "node index.js", } ...
Что-то из этого может показаться знакомым. Возможно, у вас уже есть сценарии «сборки» и «запуска», как показано выше; однако, что нового, так это сценарии «precommit» и «prepush». Это специальные имена, которые хаски распознает для запуска всякий раз, когда вы пытаетесь выполнить git commit
или git push
соответственно.
Также обратите внимание: я использую локальные файлы webpack
и eslint
из папки node_modules
. Это связано с тем, что разные проекты могут использовать разные версии этих зависимостей для разработчиков. Таким образом, когда другой разработчик начинает работать над моим кодом, зависимости становятся локальными и не зависят от того, какую версию webpack
или eslint
они могут использовать или установить на своей машине.
Теперь вы можете подумать, что еще я должен сделать? Ответ: ничего. Если вы когда-либо работали с git hooks раньше, вы должны знать, насколько это потрясающе.
Если вам нужны дополнительные советы от TalkRise, посетите наши бесплатные вечерние воркшопы для компаний, а также курсы по React, Angular и Node!