6 февраля 2026 вышел ESLint 10.0.0. Для фронтенд-команд такие релизы почти никогда не выглядят вдохновляюще: никто не мечтает провести неделю в конфиге, спорить о правилах и чинить сотни замечаний, половина из которых вообще не влияет на продукт.

Именно поэтому обновление линтера часто откладывают до последнего. А потом оно приходит не как спокойная техническая задача, а как неприятный сюрприз в момент, когда нужно обновить другой кусок toolchain. Проблема здесь не в ESLint и даже не в количестве правил. Проблема в том, что линтер обычно становится смесью старых компромиссов, устаревших плагинов и привычек команды, которые никто давно не пересматривал.

Если смотреть на переход трезво, обновление до ESLint 10 — это не история про “починить все предупреждения”. Это история про то, как отделить реальные проблемы качества кода от шума конфигурации и провести апгрейд так, чтобы команда не перестала доверять линтеру.

Почему обновление линтера часто откладывают

Линтер редко ломает прод напрямую, поэтому им удобно заниматься “когда будет время”. Но цена откладывания здесь растет скрыто.

Со временем накапливаются:

  • плагины, которые уже живут своей жизнью;
  • правила, включенные когда-то для одной цели, но давно потерявшие смысл;
  • локальные eslint-disable, которые скрывают не только шум, но и реальные проблемы;
  • расхождение между тем, что команда считает хорошим кодом, и тем, что реально проверяет инструмент.

В какой-то момент линтер перестает быть полезным guardrail и становится фоновой помехой. Самый опасный симптом — когда разработчики уже автоматически игнорируют часть его вывода.

С чего начать переход на ESLint 10

Самая большая ошибка — обновить все пакеты сразу, получить поток ошибок и начать чинить их без разбора.

Рабочий порядок намного проще.

1. Зафиксируй текущее состояние

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

2. Раздели обновление на два вопроса

После апгрейда тебе нужно ответить не на один, а на два разных вопроса:

  • что изменилось из-за новой версии ESLint;
  • что в проекте и так давно было проблемой.

Если смешать это в одну кучу, команда быстро устанет и начнет воспринимать любое изменение как произвол инструмента.

3. Проверь конфиг и плагины раньше, чем код

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

То есть первый слой проверки — не файлы приложения, а сам lint stack:

  • базовый config;
  • расширения и shareable configs;
  • плагины для React, TypeScript, Testing Library и импортов;
  • CI-команды и autofix workflow.

4. Сразу группируй вывод

Если появились новые замечания, раскладывай их по категориям:

  • config noise;
  • plugin mismatch;
  • stylistic changes;
  • реальные quality issues;
  • old debt, который раньше просто никто не трогал.

Это резко снижает ощущение хаоса.

Где обычно появляется лишний шум

Плагины и версии

Линтер почти никогда не живет один. Он живет в связке с плагинами и пресетами. Поэтому после апгрейда ESLint нередко оказывается, что основная проблема не в новой версии ядра, а в том, что экосистема вокруг него обновляется неравномерно.

Если сразу не проверить этот слой, можно начать чинить код там, где проблема на самом деле в toolchain.

Старая стилистика, которая больше никому не нужна

Вторая распространенная зона — правила, которые когда-то появились ради единообразия, а теперь только засоряют дифф.

Это хороший момент задать себе неприятный, но полезный вопрос: какие правила реально защищают кодовую базу, а какие существуют просто по инерции?

Хорошее правило линтера обычно:

  • ловит ошибку до runtime;
  • предотвращает хрупкий паттерн;
  • упрощает review;
  • делает код предсказуемее для команды.

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

Локальные отключения и обходные пути

После апгрейда часто всплывают места, где проект годами жил на eslint-disable и комментариях “разобраться потом”.

Это раздражает, но в реальности полезно. Такие зоны не обязательно чинить сразу, но их наконец становится видно.

Как обновлять линтер без паралича команды

Здесь хорошо работает принцип маленьких предсказуемых шагов.

Сначала выровняй инструментальный слой

Приведи в порядок базовый стек:

  • убедись, что плагины совместимы;
  • убери явно устаревшие расширения;
  • проверь, что CI и локальная команда используют один и тот же lint entry point.

Потом раздели ошибки на fix-now и fix-later

Сразу исправлять стоит то, что:

  • реально указывает на баг или хрупкий код;
  • массово повторяется и чинится одним приемом;
  • мешает стабильному CI.

Отложить можно то, что:

  • относится к спорной стилистике;
  • требует слишком большого механического diff;
  • дает мало пользы прямо сейчас.

Не превращай апгрейд в идеологическую чистку

Переход на новую версию линтера — плохой момент для войны за “идеальный кодстайл”. Если смешать технический апгрейд со спором о вкусах, процесс почти гарантированно затянется.

Намного полезнее держаться вопроса: какое правило помогает команде ловить реальные ошибки и держать код читабельным?

Когда нужен staged rollout

На маленьком проекте можно обновить линтер и быстро все выровнять за один проход. На большом проекте это часто плохая идея.

Staged rollout полезен, если:

  • линтер проверяет большую и неоднородную кодовую базу;
  • в проекте много старых правил и локальных исключений;
  • над кодом работает несколько человек одновременно;
  • есть риск, что одна большая lint-ветка быстро протухнет.

В таком случае лучше:

  • сначала стабилизировать конфиг;
  • потом включить только критичные правила;
  • затем постепенно вычищать остальной шум.

Иначе команда запомнит не то, что ESLint помогает держать качество, а то, что обновление линтера ломает рабочую неделю.

Итог

Переход на ESLint 10 — это не экзамен на преданность линтингу и не повод чинить все предупреждения мира. Это шанс привести в порядок слой качества кода, который обычно живет дольше любой одной фичи.

Если нужен самый практичный следующий шаг, он простой: обнови линтер на отдельной ветке, раздели новые сообщения на config noise, plugin issues и реальные code issues, а затем исправляй только то, что действительно повышает надежность и читабельность проекта. Именно так линтер остается инструментом, которому команда верит, а не фоновым генератором шума.