Система конфигурации ESLint изначально строилась вокруг файлов
.eslintrc, которые поддерживали несколько форматов: JSON,
YAML и JavaScript. Конфигурация могла наследоваться, расширяться через
extends, переопределяться через overrides и
дополняться плагинами. Такой подход долгое время обеспечивал гибкость,
но с ростом сложности JavaScript-экосистемы начал демонстрировать
структурные ограничения.
Развитие фронтенд-инструментария привело к появлению монорепозиториев, ESM-модулей, TypeScript-интеграций и сложных цепочек трансформаций кода. На этом фоне модель конфигурации ESLint начала терять предсказуемость и масштабируемость.
Одной из ключевых причин появления новой системы стала сложность механизма объединения конфигураций.
Старый подход использовал несколько уровней наследования:
extends для базовых конфигурацийoverrides для условий по файламВ результате формировалась сложная система приоритетов, где итоговое поведение линтера зависело от порядка деклараций, структуры зависимостей и особенностей резолвинга пакетов.
Особые проблемы возникали при:
overridesКонечная конфигурация становилась неочевидной без фактического выполнения резолвинга ESLint, что усложняло отладку и поддержку.
Старый механизм конфигурации требовал значительных затрат на этапе инициализации.
Причины:
extendsnode_modulesПри больших проектах с монорепозиториями это приводило к заметной задержке старта ESLint.
Особенно критичным становилось:
Поддержка JavaScript в .eslintrc.js давала гибкость, но
одновременно создавала неопределённость.
Основные проблемы:
Конфигурация переставала быть декларативной и превращалась в исполняемый код, что противоречило идее предсказуемого инструмента анализа.
Механизм overrides позволял применять разные правила для
различных файлов, но его поведение становилось всё более сложным.
Проблемные аспекты:
При росте числа файловых групп система становилась трудной для сопровождения и масштабирования.
Переход экосистемы на ES Modules выявил ограничения старой системы конфигурации.
Проблемы включали:
ESLint долгое время поддерживал гибридный подход, но это увеличивало технический долг и усложняло архитектуру.
Современные проекты часто включают десятки пакетов в одном репозитории. В старой системе это приводило к следующим проблемам:
Особенно сложными становились случаи, когда разные пакеты требовали:
Система .eslintrc не обеспечивала эффективной модели
изоляции конфигураций.
Плагины ESLint исторически не только предоставляли правила, но и могли экспортировать конфигурации.
Это приводило к нескольким проблемам:
Фактически конфигурация становилась распределённой системой, где итоговое поведение зависело от цепочки подключённых пакетов.
Старая система не имела единой формализованной структуры представления конфигурации.
Конфигурация представляла собой смесь:
Отсутствие строгой модели приводило к тому, что:
Одним из ключевых архитектурных требований стала предсказуемость результата линтинга.
В старой системе итоговая конфигурация могла изменяться в зависимости от:
Это создавало проблемы при:
Новая модель конфигурации была направлена на устранение этих неопределённостей.
ESLint начал активно использоваться не только как CLI-инструмент, но и как часть IDE-инфраструктуры.
Это потребовало:
Старая система конфигурации плохо подходила для таких сценариев из-за своей динамической природы и сложного процесса наследования.
Общий вектор изменений заключался в переходе от гибридной (декларативно-императивной) модели к строго декларативной.
Ключевые цели новой архитектуры:
Старая система конфигурации перестала соответствовать этим требованиям из-за накопившейся исторической сложности и большого количества обратной совместимости.
При работе с крупными проектами разработчики сталкивались с необходимостью вручную интерпретировать итоговую конфигурацию ESLint.
Причины сложности:
Отсутствие простой модели «вход → итоговый набор правил» делало анализ конфигурации трудоёмким и подверженным ошибкам.
Совокупность перечисленных факторов привела к необходимости пересмотра архитектуры конфигурации ESLint. Основной акцент сместился на:
Эти причины сформировали фундамент для появления новой конфигурационной модели, ориентированной на более строгую и оптимизированную структуру управления правилами анализа кода.