Comments 23
О, вы нашли npm-пакет, функционал которого может вопроизвести любой квалифицированный программист?
Даже не обязательно квалифицированный
Ха, у нас на проекте он есть, но ставил не я. Но мне было лень смотреть что это и как работает. Забавно, забавно.
у нас есть два проекта, которые начинали не мы. На одном давно посотрели, спросили "а нафиг этот хаски нужен?" И выпилили его. Ну просто как раз по причине того, что е поняли, нафига он нужен и его притащил какой-то чувак, который проект и стартовал.
Другой проект пришёл недавно. Там ещё смешнее - открываю gilab-ci и там прям в каждом стейдже первая команда что-то типа rm .git/hooks/* . Сначала я сидел и гадал, типа "а зачем", ведь посмотрел я хоку и там ничего интересного, чего их удалять? Потом поговорил с разрабами прошлыми и понял, что они сами плохо понимают, что понаписали. Ну а потом выпиливали 100500 скриптов, которые они туда натащили на каждый чих. И да, там был хаски, который делал какую-то фигню
никогда такого не было и вот опять:)
С одной стороны я согласен с автором - если есть простой способ сделать что-то без лишних зависимостей - им надо пользоваться.
С другой - надо быть очень нудным человеком чтобы знать какие ещё фичи есть в гите.
Называйте меня нудным/душным, но ИМХО, знать в git что-то кроме "git add .; git commit -m 'some fixes'; git push" это необходимость для программиста, а не узкие знания нужные единицам
Нудным? Сильное заявление. Нет, не надо быть нудным. Надо просто хоть немного знать инструмент, которым пользуешься. Тем более разрабы чаще всего не читают доку по гиту, а юзают то, что есть в IDE. Т.е. там уже всё сделано за вас.
И что, ваш пример у пользователей на винде тоже будет работать?
Теперь, чтобы у всех контрибьюторов git знал где хранятся файлы-хуки
Или можно закоммитить .gitconfig в корне с
[core]
hooksPath = .git-hooksНе смотря на то, что все равно, нужно сказать git, что «и из этого файла считай конфиг», это кажется более удобным, чем bashizm в файлах npm
Кстати да! И дело даже не в удобстве, ведь кто-нибудь может из соображений безопасности включить ignore-scripts, тогда установка наших хуков будет ожидаемо скипнута (как и установка husky, впрочем). В статье я все же оставлю небольшой башизм, исключительно для простоты восприятия читателем (чтобы без добавления еще одного конфига), но спасибо за дополнение!
Это ещё что, вот ребята портировали эту штуку на Rust, и блин сделали чтобы она ставилась по команде cargo test. Вот для кого отдельный котел в аду надо.
https://github.com/rhysd/cargo-husky
Хотел вспомнить еще про либы uppercase/lowercase, но там вроде здравомыслие победило и повесили deprecated ворнинги.
https://www.npmjs.com/package/upper-case-first
Хотя 7 месяцев назад там ещё кто-то выпустил версию 3.0!
Предложенный вами упрощенный подход работает только в простом случае единого системного интерпретатора node и не будет работать при использовании современных систем управления версиями интерпретаторов, таких как mise.
Например, типовой скрипт pnpm lint-staged упадет с ошибкой:
.git-hooks/pre-commit: line 2: pnpm: command not found
в то время как с husky он не упадет, так как husky имеет свою точку входа, которая запускает дополнительную инициализацию через ~/.huskyrc.
Ни-че-го.
Вы забыли прикрепить еще содержимое собственно точки входа husky (.husky/_/h), которая как раз и добавляет эту ценность.
P.S. Не следует использовать postinstall, нужно использовать prepare. postinstall выполняется в том числе когда ваш модуль устанавливается как зависимость для другого модуля, то есть при этом он будет или показывать ложное сообщение об ошибке, или портить конфиг гита пользователям.
Это не "упрощенный подход", который работает "в простом случае", а базовый подход, с которого каждый может начать (и которым подавляющее большинство и ограничится). Если вам для ваших нужд необходимо что-то еще, то я уверен, что вы сами добавите в файл хука необходимую инициализацию и это будет читаться лучше, чем вся та грязь, которую порождает husky по умолчанию для любого hello world проекта. Насчет prepare согласен полностью — сейчас поправлю
Хм, пользуюсь mise (еще когда он назывался rtx), не должно там быть такой проблемы - там хук на смену cwd, который по .mise.toml (.rtx.toml, .{node|python|ruby}-version, etc.) должен добавить в начало PATH путь до нужного интерпретатора.
Вообще, раньше еще рекомендовали добавить shims в PATH, как раз для интеграции с IDE и другими утилитами, которые не могут опираться на хуки в терминале
.gitconfig в корне репозитория не будет работать по умолчанию.
В этом можно убедиться посмотрев из каких источников git берет конфиг `git config --list --show-origin --show-scope`.
Его (.gitconfig) нужно добавлять отдельной командой `git config --local include.path ../.gitconfig`
Проще тогда сделать как описано в статье, и не заморачиваться с .gitconfig
Буквально на днях обновил мажорную версию husky на рабочем проекте и перестали работать хуки. Полез ресерчить и оказалось, что автор либы добавил "фичу" игнорирования шебангов в начале файла и теперь всегда используется shell. У нас скрипты были написаны на bash.
Спасибо автору статьи, теперь выпилю husky с проекта ?
Выкиньте свой husky