#1 ESLint & Prettier - Партизанщина

[@timofeyaksyonov2346]

буквально сейчас столкнулся с проблемой в prettier. По сути комментарий // prettier-ignore или /* prettier-ignore */ не работает глобально на весь файл, а действует только локально на код под ним. Можно вопользоваться прагмой: Во все файлы добавить: /** * @noprettier * @noformat */ Для разрешения преттификации конкретного файла нужно менять на /* * * @prettier * @format */ * впринципе и @format хватит. Что не совсем удобно и как правило будет забываться: удалять комментарий всеже проще чем его редактировать. Полное удаление комментария с прагмой не поможет, так как преттир ждет либо в CLI либо в конфиге параметры: --require-pragma / requirePragma если этот праметр не использовать то преттериться будет любой файл с любой прагмой. Из-за такой особенности преттира пре-коммит хуки из-за необходимости использовать прагму становятся бесполезными 🙁 === Как вариант мы сейчас решили пойти немного по такому пути, он в видео рекомендовался: 1) Настроить преттир у каждого локально в IDE; 2) При работе над таском, багом и т.д. делать первым коммитом претификацию того файла над которым идет работа; 3) Решать задачу в данном файле; 4) Коммитить изменения. Для нескольких файлов повторять шаги 2-3-4

[@eugene684]

Может кому пригодится команда добавления комментов в начало файлов(bash linux): find ./src -name '*.js' | while read A ; do sed -i -e '1 s/^/\/* eslint-disable *\/ \/* prettier-ignore *\/ /;' "$A" ; done

[@kkulebaev]

Спасибо большое, ты сэкономил мне кучу времени :)

[@tot-medved]

Просто шикарно.

[@nickstojanovic9663]

Подписка, лайк. Все по полочкам, вопросов не осталось.

[@Dozortsev]

Спасибо большое за видео!

[@dmitrijponkin]

Спасибо!!!

[@devschacht]

Можно не писать везде игнор, а просто загонять в линтер только те файлы, что были изменены в этой ветке.

[@kirillshabanov9905]

Как это реализовать?

[@mazZZzilaplayer]

Элегантно, спасибо

[@РусланБайгунусов-г9з]

А добавление eslint-ignore в каждый файл не портит историю коммитов?

[@JavaScriptNinja]

В масштабах файлов - конечно, но ценность истории в масштабах файлов низка. В масштабах строк - не портит

[@doomer_haskell]

Какой смысл в гитблейме если ты «усыновляешь» код? Ты же не побежишь к старым разработчикам с вопросом - ты сделал, ты и фикси.

[@doomer_haskell]

А если разработчик не удосужился прикрутить линтер, то и коммит месседжы врядли тебе сильно помогут.

[@ciberus]

@@doomer_haskell + тут видимо подразумевается что код ты усыновил, но старый батек остается :D

[@JavaScriptNinja]

@@ciberus Не только, иногда важно быстро посмотреть контекст в котором была добавлена строчка. Поэтому не хочется терять историю

[@kd8437]

+Дмитрий Коваленко К старым разработчикам может и не побежишь, зато знание того, кто это изменил интересующую строчку, поможет понять, почему он это сделал. Так как ты находишь коммит, по коммиту находишь, к какой таске относился этот код (может это фикс какого то бага был или еще что то) и сразу понимаешь, зачем что либо было добавлено и почему. Работу с проектом сильно облегчает, поэтому само собой лучше не терять историю гита по строкам файлов.

[@TheWorldPeace]

Видно что опыта правки чужого кода нету)

[@shpagin_dev]

Спасибо, Илья как раз на проекте сейчас линтера нет, надо внедрять как-то

[@vasylnahuliak]

4:45 я б не сказав що подружити eslint та prettier проста справа Дякую за відео. Зручно скинути його розробникам на проєкт в якому не було з самого початку eslint та prettier (писати код на JS без цих інструментів нереально незручно)

[@eldardadashov211]

И еще один вариант, просто закомитить это все и hash комиита залить в blame ignore) В будущем видео узнал

[@Acid31337]

Можно на git хуки поставить eslint только измененных файлов )

[@strpasha]

Будут проблемы при ревью, когда много изменений + 70% это изменение пробелов и т.д. + потом резолвить кучу конфликтов. Мой подход наоборот: в таске только изменения касающиеся таска, если требуются изменения кодстайла, то делается отдельный таск, и выполняется отдельно, в то время когда нет параллельных крупных тасков и обговаривается на дейли митинге чтобы все члены команды учитывали это.

[@torodinson5260]

надеялся тут знакомство с интсрументами

[@pav2k]

Второй вариант хорош, только прийдется отменять hooks от husky, или через --no-verify. А это уже хуже...