Comments 32
А можно эту же статью на английском? Я бы своим показал.
И спасибо за идею: как будете в районе Таганки в Москве, пишите, угостим чем-нибудь)
Ну и пошел включил prettier у себя в репах, до кучи. Это занимает сильно меньше 20 минут, если линтер уже есть.
Имхо, гораздо удобнее post-save.
Например для VSCode есть плагин такой.
Кроме того, часто бывает более выразительно написать в одном месте, скажем, разреженно, а в другом — компактно.
// prettier-ignoreА вот если вам постоянно нужно это куда-то писать — это повод задуматься о причинах. Исключения, подтверждающие правила, хороши только тогда, когда это и вправду исключения, а не когда под их соусом пытаются пропихнуть своё особое мнение.
Мой тезис в том, что если в 2020-м человек о таких инструментах никогда не слышал — вероятно он и есть джун, и использование Prettier для него будет в пользу. Но я против практики навязывания этого инструмента как обязательного или как бесспорно хорошей практики.
Цель Prettier сделать код красивым и выразительным.
Это не цель. «О вкусах не спорят». Цель prettier — привести весь код к констистентному виду. Можете это прямо с их сайта прочитать. Именно поэтому у prettier минимум опций, и они не собираются это менять.
Этого же можно добиваться и линтером, но линтеры наоборот тяготеют к полному конфигурированию каждого чиха, из-за чего с ними во-первых долго возиться, а во-вторых — применив парочку более сомнительных оформительских правил, можно вызвать бурные протесты внутри команды. В prettier экзотического форматирования нет вовсе, а по основным случаям можно не соглашаться, но это явно не случаи разряда «вижу такое форматирование — и аж аппетит портится, а рука сама выводит заявление по собственному».
Но когда вы работаете в опытной команде людей, которые не косячат — Prettier играет роль того самого джуна, который услышал о лучшей практике и пытается пихать её везде, уместно и не уместно, создавая больше шума, чем пользы.
Когда я работаю в команде опытных людей — я всё так же предпочитаю не раздражаться, увидев в коде «if() {» вместо «if () {». Вы можете сказать «ну так не раздражайся, и пиши у себя как надо, а читай чужой код с ледяным спокойствием», но в итоге это выливается в бесполезный шум в коммитах (если я буду править чужой if, я машинально добавлю пробел, а мой коллега, пробел не любящий — будет править, и уберет пробел), и служит вялотлеющим источником конфликтов.
const { short, line } = this.props;
const {
longLongLineElement1,
longLongLineElement2
} = this.state;
когда одни инструкции получаются развернутыми, а другие сжатыми, хотя они могут быть очень близки и структурно, и идейно, и даже по длине (например, 79 и 81 при максимуме стрики 80). Да, в 95% случаев Prettier срабатывает корректно, и только в 5% промахивается. Но когда работаешь в команде, где в 99% люди пишут верно — от Prettier с его промахами больше вреда.
при изменении пары символов в коммите часто меняется по 10 строк и пулл-реквесты становятся нечитаемыми
А почему такое происходит? Вы используете prettier вместе с lint-staged, только для изменённых файлов? В такой ситуации можно однократно прогнать весь код через форматтер, закоммитить, и тогда все будущие коммиты не будут содержать лишних изменений
Работаю front-end разработчиком, всегда код форматирую в последнюю очередь с помощью настроенной gulp сборки и потом отправляю на коммит и никаких проблем.
prettier реально напрягает в работе в реальном времени
Использую Prettier почти три года и могу сказать, что у него есть свои плюсы и минусы, как и у любого другого инструмента.
Порой Prettier совсем невнятно форматирует код или форматирование может зависеть от любопытных хаков. Например год назад я предложил вот такой https://github.com/prettier/prettier/issues/1974#issuecomment-385277713, правда теперь он уже не нужен, так как по итогам обсуждения обновили правила форматирования и теперь оно такое, какое я и хотел, по-дефолту))). Не всегда изменения, сделанные им, удобно просматривать в diff-ах.
Но в то же время, даже если не использовать Prettier как основной форматтер, он довольно удобен для форматирования вспомогательных файлов. Markdown, JSON, Yaml, вот это вот все. Я на проектах использую его вместе с ESLint и вполне доволен. Кстати ESLint еще может определять и частично исправлять всякие дурацкие ошибки, поэтому в плане чистоты кода пользы от него намного больше. Prettier предназначен исключительно для форматирования кода, и хотя его и пытаются иногда притянуть на проект в качестве линтера, это неправильно. Но вместе они позволяют на ревью обсуждать действительно важные вещи: что и как этот код делает, а не всякую фигню, вроде отсутствия/наличия пробелов в каких-то конструкциях.
Так что Prettier вполне успешно можно использовать в качестве форматтера поверх линтеров, а также для файлов, для которых линтер не особо нужен, а вот форматирование было бы выдерживать неплохо. При этом на проекте будет стайлгайд "prettier-like". Если Prettier чем-то не понравился (например ньюансами как в https://habr.com/ru/company/skyeng/blog/484992/#comment_21186642), помимо него есть еще куча "zero config" решений: xo, Lynt например. Можно тот же ESLint использовать и для форматирования с каким-нибудь популярным готовым набором правил, от airbnb например. Какой бы инструмент не был бы выбран, на хуки гита его можно повесить с одинаковым успехом и он так же перед коммитом поправит форматирование кода. Стайлгайд только будет немного отличаться. Но что останется неизменным — так это то, что стиль кода внутри проекта будет одинаковым. Чего собственно и добивались, и это экономит силы и нервы людей на проекте. Удачного code review!
Мы сделали так. В CI на гитабе подключили в том числе прогон линтером. Тесты просто не проходят если есть какое-то форматирование отличное от того что задано линтером.
Ну и понятно — пока тест красный — код можно даже и не смотреть. Разве что написать реквестеру — что тесты не прошли.
По итогу — годится причесывать небольшие файлы, которые можно сразу отсмотреть, или куски кода (хотя «формат выделенного» игнорирует отступы вокруг), а вот проходиться им по большому проекту я бы стал с крайней осторожностью. Ну и Format on save точно не стоит использовать.
Вместо кода типа:
public listenDndForFocusEvents(channel: string): Observable<boolean> {
return this.drag.pipe(
filter(event => event.channel === channel),
filter(event => event instanceof DndDragStartEvent || event instanceof DndDragEndEvent),
map(event => event instanceof DndDragStartEvent),
);
}Я всегда наблюдал что-то вроде:
public listenDndForFocusEvents(
channel: string
): Observable<
boolean
> {
return this.drag.pipe(
filter(event => event.channel === channel),
filter(
event =>
event instanceof DndDragStartEvent ||
event instanceof DndDragEndEvent
),
map(event => event instanceof DndDragStartEvent),
);
}Чего стоят if-ы вроде:
if(
exp1 &&
exp
) {
// ....
}В чем проблема использовать более вменяемый(конфигурируемый) корректировщик формата кода, я не знаю.
Так в Prettier тоже есть опция printWidth, можно там выставить значение побольше, чем дефолтные 80
Хотя в доках prettier пишут, что эту ширину стоит выставлять поменьше, я пришел к строго обратному выводу: стоит выставлять побольше.
Prettier в крупных проектах: тратим 20 минут на настройку, забываем о форматировании навсегда