Closed illright closed 1 year ago
TLDR:
Не вижу проблемы, чтоб заводить хуки 🌚
Хуки не будут прогонять билд всей кодобазы, чтобы убедиться что ничего не поломалось)
Это нужно скорее для того, чтобы люди хотя бы дожидались CI, прежде чем пинговать ревьюверов к ревью (так должно было быть в идеальном мире, где CI запускался бы сразу для новых контрибьюторов - но щас пока приходится все равно вручную, так что пункт чеклиста про CI неактуален пока, как про это и писал)
И да разразится небо новым холиваром 😄
Лично я перестал уважать гит-хуки, учитывая их "избыточноую строгость" при столь малой профитности Особенно учитывая, что их скипать можно на раз два (т.е. без CI уже никак не обойтись все равно)
И кмк бывают все равно случаи, когда "быстрые грязные коммиты >> эталонные растянутые коммиты"
Можно еще этот тред глянуть
@feature-sliced/core @feature-sliced/contributors Будут мнения? 🤔
Стоит учесть, что хуки можно ставить не только на коммит, но и на пуш. Я понимаю, почему людям не нравятся хуки на коммит (хотя я их люблю), но на пуш, на мой взгляд, можно и поставить. Ибо нет разницы, что CI упадет на сервере, что он упадет сразу, все равно исправлять. А так хотя бы можно исправить, не отходя от кассыкомпа
Да там и с пушом не без проблем) Лично я не сильно против, если кортиме идея зайдет - но сам сколько наблюдаю, в последнее время все больше от гитхуков отходят 🤔
Лично я перестал уважать гит-хуки
Тоже вызывают только раздражение. Особенно на коммитах, особенно когда тебя просят просто залить что-то побыстрому показать, а тебе приходится скипать этот матюгальник.
Ах да, ещё мне в хуки хотелось запихать commitlint, чтоб все писали конвеншионал коммитами. Не думаю, что это изменит ваше мнение, но тем не менее, сказать стоит)
Опять же - намерения хорошие, но все херится --no-verify
:)
(тоже были всякие эксперименты с commitlint)
Хз, почему вы боитесь --no-verify
. Обычно этой штукой пользуются разумные люди, у которых есть причины так сделать. А неразумные люди так или иначе найдут способ запушить фигню, что отловится на этапе ПРа (и сложит о них соответствующее мнение)
То есть, мне хочется, чтоб хуки помогали нормальным контрибьюторам быть продуктивнее, а не оберегали репо от хреновых контрибьюторов.
Ожидаю, что на это вы скажете, что хуки только бьют по продуктивности тем, что мешают. Для меня, любителя чистых коммитов, они позволяют не держать в голове соглашения по коллаборации и все равно быть уверенным, что я запушил не кринж)
Тут, боюсь, что "что для одного забота и продуктивность", то для другого "обвесились запретами, а теперь контрибьють им - да фиг там"))
Признаюсь, что даже при моей любви к дотошности и местами перфекционизму в флоу разработки - хуки для меня оч спорная вещь в плане "чистоты и профитности"
Но я уже начал повторять себя, так что послушал бы @feature-sliced/core и @feature-sliced/contributors 🤔
Ну, мне, впрочем, двух мнений кортимы достаточно, чтоб закрыть вопрос и ишью. Мне ок и без хуков, так что можно особо и не ждать, наверное)
Ты погоди))
Щас @unordinarity или @RinAkaia ворвутся - все может поменяться в обратную сторону 😏
Я скорее за хуки, чем против
For this task, Husky and lint-staged are a match made in heaven. This will help to prevent submissions that don't pass static checkers (without the need of a entry about it in the PR checklist).