Может кому пригодится команда добавления комментов в начало файлов(bash linux): find ./src -name '*.js' | while read A ; do sed -i -e '1 s/^/\/* eslint-disable *\/ \/* prettier-ignore *\/ /;' "$A" ; done
буквально сейчас столкнулся с проблемой в prettier. По сути комментарий // prettier-ignore или /* prettier-ignore */ не работает глобально на весь файл, а действует только локально на код под ним. Можно вопользоваться прагмой: Во все файлы добавить: /** * @noprettier * @noformat */ Для разрешения преттификации конкретного файла нужно менять на /* * * @prettier * @format */ * впринципе и @format хватит. Что не совсем удобно и как правило будет забываться: удалять комментарий всеже проще чем его редактировать. Полное удаление комментария с прагмой не поможет, так как преттир ждет либо в CLI либо в конфиге параметры: --require-pragma / requirePragma если этот праметр не использовать то преттериться будет любой файл с любой прагмой. Из-за такой особенности преттира пре-коммит хуки из-за необходимости использовать прагму становятся бесполезными 🙁 === Как вариант мы сейчас решили пойти немного по такому пути, он в видео рекомендовался: 1) Настроить преттир у каждого локально в IDE; 2) При работе над таском, багом и т.д. делать первым коммитом претификацию того файла над которым идет работа; 3) Решать задачу в данном файле; 4) Коммитить изменения. Для нескольких файлов повторять шаги 2-3-4
4:45 я б не сказав що подружити eslint та prettier проста справа Дякую за відео. Зручно скинути його розробникам на проєкт в якому не було з самого початку eslint та prettier (писати код на JS без цих інструментів нереально незручно)
Будут проблемы при ревью, когда много изменений + 70% это изменение пробелов и т.д. + потом резолвить кучу конфликтов. Мой подход наоборот: в таске только изменения касающиеся таска, если требуются изменения кодстайла, то делается отдельный таск, и выполняется отдельно, в то время когда нет параллельных крупных тасков и обговаривается на дейли митинге чтобы все члены команды учитывали это.
+Дмитрий Коваленко К старым разработчикам может и не побежишь, зато знание того, кто это изменил интересующую строчку, поможет понять, почему он это сделал. Так как ты находишь коммит, по коммиту находишь, к какой таске относился этот код (может это фикс какого то бага был или еще что то) и сразу понимаешь, зачем что либо было добавлено и почему. Работу с проектом сильно облегчает, поэтому само собой лучше не терять историю гита по строкам файлов.
