#новость дня

Кто-то тут не использует Prettier? Ладно, это я могу понять.

Но если кто-то не использует ESLint — проследуйте на выход, пожалуйста. Ладно, шучу. Но без этого в больших проектах никуда вообще. IDE подскажет многое, но процессы важнее.

Так вот, долгое время у многих (и у меня) возникали сомнения в нужности одновременного использования и форматтера aka Prettier и линтера aka ESLint.

Например, ESLint с лёгкостью может повторить все возможности Prettier и даже больше. Вот только... вот только надо ли?

Конфигурация становится раздутой, даже можно сказать, сложной. Начинаются споры о количестве свойств объекта на одной строке. Обязательно найдётся кто-то с очень важным мнением и обидится.

Но давайте честно. Задача линтера — прививать хорошие привычки кодирования и не давать неосознанно писать говнокод применять плохие практики. Да, JavaScript — язык, в котором слишком много можно написать слишком плохо.

А вот форматтер — уже чистая вкусовщина. В целом, каждая IDE умеет так или иначе применять форматирование к уже написанному коду, но остаётся вопрос распространения этого на команду и процессы деплоя.

Потому Prettier остаётся хорошим выбором. Тот факт, что он уже внедрён в огромное число проектов с минимальными изменениями в конфигурации по-умолчанию, даёт уверенность в том, что люди не будут тратить время на споры (не даёт, но то такое).

К чему я веду? А вот: https://eslint.org/blog/2023/10/deprecating-formatting-rules/

Для тру: ESLint 10 больше не будет поддерживать настройки форматирования кода и вся работа ляжет на плечи сторонних средств форматирования (предлагаются Prettier, dprint и stylistic). Начиная с версии 8.53.0 эти настройки будут объявлены устаревшими.

Это сильно облегчит работу разработчиков ESLint и позволит им сосредоточиться на внедрении хороших практик, нежели на вкусовщине.

А как дела на ваших проектах, котаны?

#eslint #prettier

#такое дня

Для чего нужны линтеры и форматтеры? Нет, не для того, чтобы код выглядел красиво, это субъективное. Так для чего же?

Правильно, чтобы он выглядел единообразно. А ещё чтобы раз и навсегда исключить бесконечные споры о запятых, количестве строк и их длине.

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

Из-за этого мы с товарищем когда-то много спорили: когда определение объекта должно «разъезжаться» по строкам, а когда — нет.

В Dart, кстати, решено элегантно:
— есть запятая в конце — будет перенос,
— нет запятой — всё остаётся в одной строке. Сравните:

SizedBox(
  height: buttonSize / 3,
),

и

SizedBox(height: buttonSize / 3),

Для единичных значений я предпочту второе, для выражений — первое. И так далее. Именно ради удобного просмотра изменений в PR.

И вот недавно в рассылке ядра Linux Линус Торвальдс пожаловался, что rustfmtcheck меняет читабельное:

use crate::{
  xyz,
  abc,
};

на слипающееся:

use crate::{xyz, abc};

...и делает это по каким-то непредсказуемым эвристикам. Потому что правила Rust оставляют это на усмотрение утилит. В итоге, вместо помощи, форматтер ломает диффы, мешает мёрджам и ухудшает поддержку кода.

Линус подытожил просто: такие инструменты превращают аккуратный код в bass-ackwards garbage — и делают хуже, а не лучше.

Что, котаны, кто-то до сих пор сидит без Prettier? 🙂

Или уже без Prettier?

#format #prettier