#статья дня

Не так давно я писал о том, что мне пришлось написать плагин для ESLint, потому что а) среда, в которой я работаю — упоротая, б) инструменты — упоротые, в) люди тоже себя могут иногда вести... упорото.

Вот тут: https://t.me/htmlshit/1638

Мой плагин был очень простой: запрет констант уровня модуля. Ну вот так вот :( Они при сборке терялись, потому что иди нахер, вот почему.

Так, к статье дня. Анастасия Щедрина о том, как работает ESLint и о том, как написать свой плагин для линтинга React-приложения: https://habr.com/ru/companies/domclick/articles/743384/

Да, я в посте тоже писал про AST и инструменты, позволяющее это самое абстрактное синтаксическое дерево построить, но в статье тут всё гораздо подробнее. Меня редко хватает на целую статью, так что читайте что у других есть, котаны :) Ведь вышло неплохо и подробно.

#eslint #react #ast

#инструмент дня

Перфекционисты тут?

Не так давно Андрей Ситник в Твиттере поднял тему красивого кода. В данном случае под красивым кодом подразумевалась сортировка импортов (и экспортов) модулей и методов.

И вот он, ESLint плагин для всяческой упоротой и не очень сортировки импортов: https://github.com/azat-io/eslint-plugin-perfectionist

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

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

А если вы когда-нибудь вообще задавались вопросом, где зона ответственности Prettier, а где — ESLint (или любых других), на эту тему имеется соответствующая статья: https://blog.joshuakgoldberg.com/the-blurry-line-between-formatting-and-style/

TL;DR: всё, что меняет AST (пара постов выше) — зона ответственности линтера. А красотули — форматтера.

Всем perfection, котаны!

#js #eslint #beauty

#новость дня

Кто-то тут не использует 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

#статья дня

Не так давно я писал о том, что мне пришлось написать плагин для ESLint, потому что а) среда, в которой я работаю — упоротая, б) инструменты — упоротые, в) люди тоже себя могут иногда вести... упорото.

Вот тут: https://t.me/htmlshit/1638

Мой плагин был очень простой: запрет констант уровня модуля. Ну вот так вот :( Они при сборке терялись, потому что иди нахер, вот почему.

Так, к статье дня. Анастасия Щедрина о том, как работает ESLint и о том, как написать свой плагин для линтинга React-приложения: https://habr.com/ru/companies/domclick/articles/743384/

Да, я в посте тоже писал про AST и инструменты, позволяющее это самое абстрактное синтаксическое дерево построить, но в статье тут всё гораздо подробнее. Меня редко хватает на целую статью, так что читайте что у других есть, котаны :) Ведь вышло неплохо и подробно.

#eslint #react #ast #бородач

#заметка дня

Итак, котаны, у нас сегодня офигительная информация от Глеба. Вы уже с ним знакомы, он автор библиотеки extended-fetch, расширяющей возможности стандартного fetch. Горячо рекомендую, кстати.

Слово автору.

Наверняка вы сталкивались с проблемой медленного eslint и очень хотели использовать все ядра процессора

По этой проблеме существует issue в репозитории eslint аж с 2015 года, однако лишь в ноябре 2023 года появился PR с добавлением параллелизма при помощи флага --parallel (к сожалению, он до сих пор не смержен).

В комментарии к issue автор PR описывает как его вдохновил пакет @mixer/parallel-prettier: создается очередь и распределяется по процессам с воркерами, а затем их результаты выполнения аккумулируются и создается общий отчет.

По его замерам на 6 ядрах время выполнения eslint снизилось с 4 до 1 минуты исключая правила Typescript, а с ними с 4 до 2 минут.

Конечно же, предстоит решить вопрос с кеширвоанием и шарингом кеша между процессами, ну и никуда не исчезнут нюансы парсинга Typescript.

И совсем недавно появился форк eslint с поддержкой параллельной проверки нескольких файлов.

Всё это очень краткий пересказ, поэтому лучше почитать последние комментари в issue и убедиться, что всё не так плохо и прогресс в сторону улучшения производительности есть.

Всем ускорения, котаны!

#eslint #multicore #parallel

#фишка дня

Если ваш конфиг ESLint до сих пор заставляет писать rel="noopener noreferrer" в каждой targer="_blank" ссылке, вы живёте в прошлом.

Потому что писать noopener не надо.

Этот атрибут запрещает установку свойства window.opener на открытое окно, таким образом, запрещая доступ открытого окна к открывающему.

Это уже 4 года как дефолтное поведение всех (нормальных) браузеров.

Ну а ставить ли noreferrer — чтобы узнать URL, откуда пришёл пользователь — дело ваше.

#eslint #security #anchor

#ссылка дня

Когда-то мы обсуждали новость о том, что ESLint хочет перейти на новый, плоский формат конфига в своей 9 версии.

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

Это, казалось бы, удобное нововведение вызвало бурю негодования. Кто-то решил остаться на восьмой версии, кто-то нашёл это идеальным поводом чтобы уйти на какой-нибудь Biome.

Но... ESLint нас услышал! И они выкатили инструмент для миграции конфигов: https://eslint.org/blog/2024/05/eslint-configuration-migrator/

Естественно, не без ограничений (основное — поддерживается только корневая директория), но всё же.

Буду пробовать и сообщу. Я тут осознал, что вообще до сих пор на седьмом...

#eslint #tool

#инструмент дня

Зачем писать !(a && !b && c >= 10 && d !== e), если можно !a || b || c < 10 || d === e?

Ответ на эти и другие вопросы прост: «Потому что не подумал».

Но думать — сложно. И не всегда нужно. Поэтому в IDE от JetBrains встроен преобразователь логических вырадений по законам де Моргана.

А тем, кто предпочитает быть свободным, приходится искать иные решения.

Иногда — даже думать.

И тут есть вариант, откуда не ждали: правило для ESLint!

ESLint Plugin De Morgan: https://github.com/azat-io/eslint-plugin-de-morgan

Запросто преобразует ваши const value = !(a || b !== c) в const value = !a && b === c.

В плагине два правила:

- no-negated-conjunction
- no-negated-disjunction

Все правила имеют автофикс. У плагина нет зависимостей. Поддерживает как современный, так и легаси формат ESLint конфигов.

Твиттер автора с анонсом: https://x.com/azat_io/status/1888874193007132762

Пользуемся, котаны!

#boolean #eslint #logic

#инструмент дня

Сложно представить себе проект, в котором не использовался бы ESLint.

Ну разве что вы или до сих пор на TSLint или ушли на Biome.

Так вот, в прошлом году, совместно с релизом версии 9, они обозначили свои планы. А планы большие: стать основным инструментом для поддержки качества кода на фронтенде. Это значит, линтинг JS, TS, JSON, Markdown. Ну и CSS тоже.

И вот, наконец, 18 февраля команда объявила о начальной поддержке линтинга CSS: https://eslint.org/blog/2025/02/eslint-css-support/

Соответственно, выпустив плагин @eslint/css:

no-duplicate-imports - запрещает дубликаты @import rules
no-empty-blocks - запрет пустых блоков
no-invalid-at-rules - валидация @-правил
no-invalid-properties - запрет некорректных свойств
require-baseline - самое интересное, заставляет придерживаться Baseline (современных фич веба и CSS в том числе, которые поддерживаются всеми браузерами в должной мере)
use-layers - а вот это спорно, использование слоёв aka @layer. Я пока не видел никого, кто их понимает :)

Ну что, убираем Stylelint?

#css #lint #eslint

#фишка дня

Когда вызываешь async-функцию, но не обрабатываешь её результат, промис остаётся "висящим" (floating). Это может привести к разным проблемам:

Потеря ошибок.
Если промис завершается с ошибкой, но её никто не ловит, можно упустить важные сбои в коде.

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

Неоптимальное использование ресурсов.
Если промис делает сетевой запрос или что-то грузит, но результат нигде не используется, это просто тратит ресурсы впустую.

Ещё, конечно, IDE ругается и бесит.

Чтобы явно указать, что промис можно игнорировать, используй один из этих способов:

void fetchData(); // Показываем, что знаем о промисе, но он нам не нужен  
fetchData().catch(() => {}); // Глушим ошибки (осторожно, можно скрыть баги!)  
fetchData().then(() => {});  // Запускаем, но не обрабатываем результат  
(async () => { await fetchData(); })(); // IIFE, помните ещё такое?

Правило no-floating-promises (https://typescript-eslint.io/rules/no-floating-promises/) в ESLint помогает находить такие промисы и не оставлять их без внимания.

#eslint #async

#заметка дня

Как мы все знаем, в JavaScript есть две формы «пустоты»: undefined и null.

Но почти весь современный фронтенд давно выбрал сторону.

null — это ошибка на миллиард долларов, о которой пожалел даже его создатель, Тони Хоар. Он добавляет путаницу, ломает API и заставляет писать лишние проверки.

Почему null — плохая идея:
Разные API возвращают то null, то undefined, то оба.

Это неясно, это ошибки.

✅ TypeScript-гайд от Microsoft прямо говорит: используйте undefined, избегайте null.

✅ В TSLint null запрещён по умолчанию (`no-null-keyword`).

✅ Правила ESLint Unicorn (да, название неслучайное) — тоже пропагандируют борьбу с null в пользу чистого, предсказуемого кода.

✅ В крупных экосистемах, например, как у Prisma, null создаёт баги и недопонимание в API (issue #572)

✅ undefined — поведение по умолчанию в JS для необъявленных свойств и пустых объектов.

✅ undefined выигрывает даже в JSON. Когда ты сериализуешь данные:

null остаётся в объекте:

{ "a": null }

а undefined просто исчезает:

{ "a": undefined } → { }

В реальных системах это даёт выигрыш в размере и читаемости. Пример из продакшена: объект с миллионом null весил 13.9 MB, а с undefined — всего 21 байт. И если ты работаешь с Node.js и хорошо контролируешь свои API — undefined тебе только на руку.

❌ Да, из-за того, что множество систем до сих пор оперирует null, и даже DOM API возвратит null при отсутствии элемента (ноды), выбор становится не настолько простым. К счастью, мы можем использовать optional chaining (?.) и nullish coalescing (??) чтобы снизить вероятность конфуза.

Кстати, даже столь любимый мной Effector ещё не так давно пропагандировал null для пустых сторов, но с недавнего времени разрешил undefined (в своей манере, там сложная концепция).

Итак, null — это рудимент. Он создаёт больше проблем, чем решает. undefined уже делает всё, что нужно — чище, предсказуемей и легче.

Пора выбрать сторону 🦄

P. S. человек, который заставил меня принять сторону сейчас, наверное, сидит и хихикает. Но в целом, единственное, что у меня есть в защиту null — это наш бакенд на PHP и MySQL 🤷

#js #ts #eslint #null

#инструмент дня

Приложение растёт, достигло невероятных масштабов, а интернационализацию не завезли?

Или так долго пилили фичи под основной язык, что переводчик-техпис успел уволиться, а техлиду не нравится ни один кандидат?

Да, это не оправдание фигачить строки без заворачивания их в уже ставший настолько привычным t(), но что-то же делать надо, согласитесь?

Итак, вашему вниманию несколько вариантов для упрощения переноса подвисших непереведённых строк в ресурсные файлы:

1. Lingui ESlint плагин — https://github.com/lingui/eslint-plugin

Да, не так много людей использует Lingui, но плагин — достаточно универсальный и гибкий. Позволит найти как строки в тегах, так и в атрибутах.

2. Сюда же ESLint плагин для чуть более привычного i18next — https://www.npmjs.com/package/eslint-plugin-i18next

Занимается буквально тем же самым, но вариантов настройки чуть меньше. Лично у меня не было времени досконально проверить вариант 1, потому я остановился на этом. Сердито и быстро. Ну и конечно, установил его в warn.

3. Ну и в качестве забавного артефакта, добавим i18next-emoji-postprocessor. Что он делает?

О, он делает дичь. Заменяет все переведённые строки на рандомные эмодзи. Что не переведено — в эмодзи не превратится. Звучит кринжово, но на самом деле может стать идеально для текучки уставшего техписа.

Конечно, идеальным решением был бы экспорт непереведённых строк в CSV, но это я пока не до конца осилил. Получится — расскажу.

А как вы с этим справляетесь, котаны?

#i18n #l10n #eslint