Подключение альтернативного парсера

ESLint работает поверх абстрактного синтаксического дерева (AST), которое строится на основе исходного кода JavaScript. Именно парсер отвечает за преобразование текста программы в структуру, пригодную для анализа правилами линтинга. По умолчанию используется парсер Espree, поддерживающий стандартный JavaScript и часть современных возможностей ECMAScript.

Парсер является фундаментальным компонентом цепочки обработки:

исходный код → парсер → AST → правила ESLint → отчёт о проблемах

Любое расширение синтаксиса языка, будь то TypeScript, JSX или экспериментальные предложения ECMAScript, требует использования альтернативного парсера, способного корректно интерпретировать соответствующий синтаксис.

Механизм подключения альтернативного парсера

В конфигурации ESLint выбор парсера задаётся через поле parser. Оно может указывать как на встроенный, так и на сторонний модуль.

Базовая структура конфигурации:

module.exports = {
  parser: "имя-пакета-парсера",
  rules: {
    semi: "error"
  }
};

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

Важно учитывать, что не каждый парсер совместим со всеми правилами ESLint. Совместимость зависит от структуры AST, которую он генерирует.

Основные причины замены парсера

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

  • использование TypeScript;
  • наличие JSX в React-приложениях;
  • применение экспериментальных возможностей ECMAScript;
  • нестандартные расширения языка или трансформации.

Каждый из этих сценариев требует специализированного анализа синтаксиса.

Подключение парсера @babel/eslint-parser

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

Установка:

npm install --save-dev @babel/eslint-parser

Конфигурация:

module.exports = {
  parser: "@babel/eslint-parser",
  parserOptions: {
    requireConfigFile: false,
    babelOptions: {
      presets: ["@babel/preset-env"]
    }
  }
};

Особенности работы

@babel/eslint-parser не выполняет трансформацию кода, а только строит AST через Babel. Это означает:

  • поддержка Stage-пропозалов ECMAScript;
  • корректная обработка нестандартных синтаксических конструкций;
  • зависимость от Babel-конфигурации при использовании сложных пресетов.

При отсутствии корректных настроек Babel возможны ошибки разбора или неполное дерево AST.

Использование @typescript-eslint/parser

Для проектов на TypeScript применяется специализированный парсер:

npm install --save-dev @typescript-eslint/parser

Конфигурация:

module.exports = {
  parser: "@typescript-eslint/parser",
  parserOptions: {
    ecmaVersion: 2022,
    sourceType: "module",
    project: "./tsconfig.json"
  }
};

Архитектурная роль

Парсер выполняет не только синтаксический разбор TypeScript-кода, но и формирует расширенную модель AST, включающую типовую информацию. Это позволяет правилам ESLint анализировать типы данных, интерфейсы и generics.

Режим project

Поле project включает режим семантического анализа через TypeScript Compiler API. В этом режиме:

  • производится проверка типов;
  • доступна информация о символах;
  • увеличивается точность правил;
  • возрастает стоимость анализа по времени.

При отсутствии project парсер работает в упрощённом режиме без полноценной типизации.

Подключение парсера для JSX и React-синтаксиса

JSX не является частью стандартного JavaScript, поэтому требует либо Babel-парсера, либо TypeScript-парсера с включённой поддержкой JSX.

Для Babel:

parser: "@babel/eslint-parser",
parserOptions: {
  babelOptions: {
    presets: ["@babel/preset-react"]
  }
}

Для TypeScript:

parserOptions: {
  ecmaFeatures: {
    jsx: true
  }
}

JSX трансформируется в вызовы функций, но на уровне AST сохраняет структуру компонентов, что позволяет правилам анализировать дерево UI-элементов.

parserOptions и влияние на поведение парсера

Каждый парсер поддерживает собственный набор опций через parserOptions. Эти параметры влияют на интерпретацию кода.

Ключевые параметры:

ecmaVersion

Определяет версию ECMAScript:

parserOptions: {
  ecmaVersion: 2022
}

Более высокая версия включает поддержку новых синтаксических конструкций, таких как ??, ?., top-level await.

sourceType

Определяет модульную систему:

  • "script" — классический скрипт
  • "module" — ES Modules

Неправильное значение приводит к ошибкам разбора import/export.

ecmaFeatures

Дополнительные возможности синтаксиса:

parserOptions: {
  ecmaFeatures: {
    jsx: true
  }
}

Используется для включения JSX или других расширений.

Совместимость парсера и правил ESLint

ESLint-правила опираются на структуру AST. При смене парсера возможны следующие ситуации:

  • правило не находит ожидаемые узлы AST;
  • структура дерева отличается от Espree;
  • часть правил становится неприменимой.

Например, правила, работающие с типами переменных, требуют TypeScript-парсера, иначе информация о типах отсутствует.

Некоторые плагины явно зависят от конкретного парсера и указывают его в документации.

Использование override-парсеров в монорепозиториях

В сложных проектах часто требуется использование разных парсеров для разных типов файлов:

module.exports = {
  overrides: [
    {
      files: ["*.ts"],
      parser: "@typescript-eslint/parser"
    },
    {
      files: ["*.jsx"],
      parser: "@babel/eslint-parser"
    }
  ]
};

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

Взаимодействие с плагинами ESLint

Плагины ESLint могут требовать определённого парсера. Например:

  • @typescript-eslint/eslint-plugin требует @typescript-eslint/parser;
  • React-плагины могут использовать Babel или TypeScript-парсер;
  • некоторые экспериментальные плагины зависят от AST Babel.

Несоответствие парсера и плагина приводит к ошибкам анализа или отсутствию проверок.

Ошибки, связанные с некорректным выбором парсера

Типовые проблемы:

SyntaxError при разборе кода

Возникает при использовании неподдерживаемого синтаксиса.

Причина: несоответствие версии ECMAScript или отсутствие нужного парсера.

Missing parser error

ESLint не находит указанный модуль парсера.

Причина: отсутствие установленного пакета или ошибка в имени.

Invalid AST structure

Правила не могут обработать дерево.

Причина: несовместимость плагина и выбранного парсера.

Влияние парсера на производительность

Разные парсеры имеют различную стоимость анализа:

  • Espree — оптимизирован для скорости;
  • Babel parser — более универсален, но медленнее;
  • TypeScript parser — самый тяжёлый из-за семантического анализа.

При увеличении объёма проекта различия становятся заметны в времени линтинга.

Расширенные сценарии использования

В крупных системах ESLint может использовать несколько уровней анализа:

  • базовый синтаксический парсинг;
  • расширенный анализ типов;
  • трансформированный AST через Babel;
  • комбинированные конфигурации через overrides.

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

Оглавление