​​#урок дня

Дэн Абрамов в своей статье о хуках в React говорит нам: «Не врите Реакту о зависимостях хука, указывайте все».

ESlint вторит ему: Этот код нужно исправить.

Но я же умный и без сопливых знаю точные зависимости, поэтому:
// eslint-disable-next-line react-hooks/exhaustive-deps

Мой UI тем временем ведёт себя вот так…

P. S. обратили внимание на ссылку с подсветкой текста? Завтра будет фишка по этому поводу.

P. P. S. Перевод статьи доступен на Хабре, но учтите, что материала там минут на сорок, на любом языке: https://m.habr.com/en/company/ruvds/blog/445276/

#react #hooks #useeffect #eslint

#видео дня

Если вдруг так получилось, что вам в этот воскресный день дождливо и грустно, советую посмотреть лекцию Жени Обрезкова с детальным разбором настроек конфигурации TypeScript и typescript-eslint. Естественно, совсем не обязательно смотреть все два с половиной часа, ведь есть оглавление. Каждый пример демонстрируется в песочнице. Подойдёт всем :)

https://youtu.be/4Vc-O20llVs

#typescript #tsconfig #eslint

#видео дня

Если вдруг так получилось, что вам в этот воскресный день дождливо и грустно, советую посмотреть лекцию Жени Обрезкова с детальным разбором настроек конфигурации TypeScript и typescript-eslint. Естественно, совсем не обязательно смотреть все два с половиной часа, ведь есть оглавление. Каждый пример демонстрируется в песочнице. Подойдёт всем :)

https://youtu.be/4Vc-O20llVs

#typescript #tsconfig #eslint

#статья дня

Всем нам так набивший оскомину хорошо знакомый ESLint наконец-то обновил формат конфигурационных файлов:
https://eslint.org/blog/2022/08/new-config-system-part-1/
https://eslint.org/blog/2022/08/new-config-system-part-2/

Первая статья рассказывает, как ESLint дошёл до жизни такой, добавляя всё больше и больше настроек, extends, :root, overrides, автоматическую загрузку зависимостей…

И вот вторая часть знаменует собой стряхивание всего лишнего и внедрение плоского формата. Нужны зависимости? Укажи прямо. Нужен extends? Не нужен, просто описывай дополнительные правила ниже. Описание сред выполнения заменилось на описывание глобальных условий. И куча изменений для плагинов.

В целом, стало проще и прямолинейнее. Посмотрим.

#eslint #js

#заметка дня

Я тут сделал свой первый ESLint-плагин! Ну и, соответственно, ввёл в наши сборки новое правило. Но обо всём по порядку.

У «моей» среды исполнения JS — Google AppsScript — есть одна неприятная особенность. А именно: в глобальный скоуп попадают все переменные, объявленные на уровне модуля. Ну и, соответственно, они друг-друга могут перезаписать.

Вообще, про забавности в разных средах JS можно целую презентацию подготовить.

Проблему можно решить используя любой бандлер, но огромную базу легаси-кода перетащить в бандлер та ещё задача, плюс, надо соблюсти условия по видимости API, поскольку в среде есть свои соглашения по приватным и публичным методам.

Потому было решено проблему видимости исключить на корню: если тебе нужен полноценный модуль, используй классы и свойства класса соответственно. Если нет — убирай свои константы в функцию. Короче говоря, понадобилось запрещающее переменные на уровне модулей правило.

С плагинами для линтера есть одна проблема: почему-то нет возможности написать своё локальное правило, в рамках репозитория проекта. Надо обязательно создавать npm-пакет… но я не хочу. По крайней мере, не сейчас.

На помощь пришёл другой плагин: eslint-plugin-local-rules.

Великолепная штука, создал eslint-local-rules.js и поехали.

Но это всё было бы гораздо сложнее разрабатывать, если бы не ещё один инструмент: https://astexplorer.net/

Abstract Syntax Tree explorer: обозреватель абстрактного синтаксического дерева. Грубо говоря, ваш код разбивается на узлы и связи между ними: вот это — оператор, это — скобка, это — определение переменной, это — присвоение значения и так далее.

Анализируя это дерево (ну и конечно, документацию ESLint и исходники других плагинов) можно вполне себе быстро реализовать задачу.

Пишите плагины для ESLint, котаны. Это не больно.

…больно разгребать глупые баги :)

#eslint #javascript #ast

#статья дня, предложка от нашего подписчика glebcha:

Изумительная детективная история о том, как производительность eslint улучшали.

В сюжете:
- ставший привычным случай замены на классический цикл for
- страх и ненависть к полифилам с их последующим удалением из процесса сборки
- исследование/оптимизация "лентяек" (в этом случае была библиотека esquery, которая предоставляет DSP для обращения к AST через css-подобные селекторы)
- «сложности перевода», точнее, как AST тайпскрипта приводить к формату estree и насколько это затратно (использование бабеля с пресетом тайпскрипта существенно ускорило процесс в ущерб типобезопасности).

С выводом автора статьи я соглашусь: инструмент с чистой и оптимизированной кодовой базой может быть быстрым и на JS, переход на Rust скорее как попытка избежать проблемы вместо решения.

Читаем: https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-3

Автор статьи — член кор-команды Preact. Третья из цикла, если что. Там много интересного.

#подписчик #eslint

#статья дня

Не так давно я писал о том, что мне пришлось написать плагин для 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