Конфигурация ESLint через package.json реализуется посредством специального поля eslintConfig, которое интерпретируется инструментом линтинга как полноценный источник настроек. Такой подход позволяет объединить метаданные проекта и правила статического анализа в одном файле, уменьшая количество конфигурационных артефактов в корне репозитория и упрощая поддержку небольших и средних проектов.
Внутри package.json добавляется объект eslintConfig, содержащий те же сущности, что и классические конфигурационные файлы ESLint (.eslintrc.*). Основная особенность заключается в том, что JSON-структура становится частью общего описания проекта.
{
"name": "project-example",
"version": "1.0.0",
"eslintConfig": {
"env": {
"browser": true,
"node": true
},
"extends": "eslint:recommended",
"parserOptions": {
"ecmaVersion": 2022,
"sourceType": "module"
},
"rules": {
"no-console": "warn",
"semi": ["error", "always"]
}
}
}Поле eslintConfig поддерживает полный набор стандартных опций ESLint, включая расширения конфигураций, правила, окружения и параметры парсинга.
При наличии нескольких источников конфигурации ESLint применяет строгую систему приоритетов. package.json с eslintConfig имеет более низкий приоритет по сравнению с более специфичными файлами конфигурации, такими как .eslintrc.json или .eslintrc.js.
Типичный порядок разрешения выглядит следующим образом:
Такой порядок обеспечивает предсказуемость поведения при масштабировании проекта, где локальные конфигурации могут переопределять глобальные настройки.
Раздел env определяет глобальные переменные и контексты исполнения, в которых анализируется код. Это влияет на то, какие глобальные идентификаторы считаются допустимыми.
{
"eslintConfig": {
"env": {
"es6": true,
"node": true,
"jest": true,
"browser": false
}
}
}Каждое окружение включает набор предопределённых глобальных переменных и правил интерпретации синтаксиса.
Механизм extends позволяет наследовать готовые наборы правил. Это основной способ повторного использования конфигураций в экосистеме ESLint.
{
"eslintConfig": {
"extends": [
"eslint:recommended",
"plugin:import/recommended"
]
}
}При использовании нескольких конфигураций порядок массива определяет приоритет: последующие элементы переопределяют предыдущие.
Распространённые значения extends:
Раздел rules является центральным механизмом управления поведением линтера. Каждое правило может находиться в одном из трёх состояний:
{
"eslintConfig": {
"rules": {
"no-unused-vars": "warn",
"no-debugger": "error",
"quotes": ["error", "single", { "avoidEscape": true }]
}
}
}Правила могут принимать массив параметров, где первый элемент задаёт уровень строгости, а последующие — конфигурацию поведения.
parserOptions определяет синтаксические особенности анализируемого кода. Это критически важно при использовании современных возможностей ECMAScript или нестандартных расширений.
{
"eslintConfig": {
"parserOptions": {
"ecmaVersion": 2023,
"sourceType": "module",
"ecmaFeatures": {
"jsx": true
}
}
}
}Основные параметры:
Плагины расширяют функциональность ESLint за счёт дополнительных правил и парсеров. В package.json они подключаются через поле plugins.
{
"eslintConfig": {
"plugins": ["react", "import"]
}
}Важно учитывать, что plugins лишь регистрируют наборы правил, но не активируют их автоматически. Для активации требуется использование extends или явное объявление правил.
Раздел globals определяет пользовательские глобальные идентификаторы, которые не должны считаться неопределёнными.
{
"eslintConfig": {
"globals": {
"MyGlobal": "readonly",
"__DEV__": "writable"
}
}
}Режимы доступа:
Механизм overrides позволяет применять различные правила к определённым файлам или паттернам.
{
"eslintConfig": {
"overrides": [
{
"files": ["*.test.js"],
"rules": {
"no-unused-expressions": "off"
}
},
{
"files": ["src/**/*.js"],
"excludedFiles": "*.min.js",
"rules": {
"strict": "error"
}
}
]
}
}Это особенно важно в проектах с разнородной структурой, где тесты, сборочные скрипты и прикладной код требуют разных правил анализа.
Поле settings передаёт общие данные в плагины, позволяя им адаптировать поведение без дублирования конфигураций.
{
"eslintConfig": {
"settings": {
"react": {
"version": "detect"
},
"import/resolver": {
"node": {
"extensions": [".js", ".jsx"]
}
}
}
}
}Эти настройки не влияют на ESLint напрямую, но используются плагинами в процессе анализа.
Использование package.json в качестве контейнера конфигурации имеет структурные ограничения. Основное из них связано с невозможностью динамической логики: вся конфигурация должна быть выражена в статическом JSON-формате.
Отсутствуют:
Это делает подход предсказуемым, но менее гибким по сравнению с JavaScript-конфигурациями.
В монорепозиториях eslintConfig в package.json часто применяется на уровне отдельных пакетов. При этом глобальные правила обычно выносятся в корневую конфигурацию, а локальные package.json служат для уточнения поведения в конкретных подпроектах.
Такой подход позволяет разделять ответственность:
Несмотря на развитие новых форм конфигурации, package.json остаётся поддерживаемым источником настроек ESLint. Однако при сложных проектах он часто уступает по выразительности отдельным конфигурационным файлам, особенно при использовании расширенных сценариев переопределения и динамической сборки правил.