eslint-plugin-prettier: запуск Prettier как правила

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

eslint-plugin-prettier решает эту проблему, превращая Prettier в правило ESLint. В результате форматирование перестает быть отдельным этапом пайплайна и становится частью линтинга.

Ключевая идея интеграции:

  • Prettier выполняет форматирование кода
  • ESLint фиксирует нарушения как ошибки правил
  • результат Prettier проверяется через ESLint-движок

Принцип работы eslint-plugin-prettier

Плагин не форматирует код напрямую в момент анализа. Он:

  1. Передает исходный файл в Prettier
  2. Получает отформатированный результат
  3. Сравнивает его с текущим содержимым файла
  4. Если есть различия — сообщает об ошибке ESLint

Таким образом, любое несоответствие стилю Prettier становится ESLint-ошибкой.

Механизм можно представить как правило:

prettier/prettier: "error"

Установка и базовая интеграция

Типовая установка включает три зависимости:

npm install --save-dev eslint prettier eslint-plugin-prettier

Часто вместе используется дополнительный пакет:

npm install --save-dev eslint-config-prettier

Он отключает конфликтующие правила ESLint, связанные с форматированием.

Конфигурация ESLint с Prettier

Базовый вариант

{
  "plugins": ["prettier"],
  "extends": ["plugin:prettier/recommended"]
}

Конфигурация plugin:prettier/recommended автоматически включает:

  • eslint-plugin-prettier
  • eslint-config-prettier
  • правило prettier/prettier: "error"

Ручная конфигурация

При необходимости более тонкого контроля конфигурация может быть развернута вручную:

{
  "plugins": ["prettier"],
  "extends": ["eslint:recommended", "prettier"],
  "rules": {
    "prettier/prettier": "error"
  }
}

Разделение ответственности здесь важно:

  • extends: ["prettier"] отключает конфликтующие ESLint-правила
  • prettier/prettier включает проверку форматирования

Поведение правила prettier/prettier

Правило анализирует файл и сравнивает его с результатом Prettier.

Пример несоответствия:

const sum=(a,b)=>{return a+b}

Prettier преобразует:

const sum = (a, b) => {
  return a + b;
};

ESLint фиксирует:

Error: Replace `const·sum=(a,b)=>{return·a+b}` with `const sum = (a, b) => ...`

Интеграция с редакторами

eslint-plugin-prettier позволяет унифицировать поведение редакторов, поскольку ESLint становится единой точкой проверки.

VS Code (типовой сценарий)

Используется комбинация:

  • ESLint extension
  • автофиксация при сохранении

Настройка:

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

В этом режиме Prettier выполняется через ESLint pipeline.

Режимы работы: проверка и автофикс

Плагин поддерживает два основных сценария:

Проверка (lint)

npx eslint src

Выводит ошибки форматирования как обычные ESLint-нарушения.

Автоисправление

npx eslint src --fix

ESLint передает исправление Prettier, и код перезаписывается в отформатированном виде.

Отличие от отдельного запуска Prettier

Без eslint-plugin-prettier обычно используется:

prettier --write .
eslint .

С плагином:

eslint . --fix

Разница заключается в том, что:

  • Prettier становится частью ESLint pipeline
  • исчезает необходимость синхронизации двух отдельных инструментов
  • ошибки форматирования становятся частью линтинга

eslint-plugin-prettier и eslint-config-prettier

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

eslint-plugin-prettier

  • запускает Prettier внутри ESLint
  • создает правило prettier/prettier

eslint-config-prettier

  • отключает конфликтующие ESLint-правила
  • предотвращает дублирование логики форматирования

Конфликтные сценарии без eslint-config-prettier

Без отключения правил ESLint могут возникать конфликты:

  • indent
  • quotes
  • semi
  • comma-dangle

Например:

"rules": {
  "semi": ["error", "always"]
}

Prettier может настроить другой стиль, и ESLint начнет противоречить самому себе.

Производительность и стоимость проверки

eslint-plugin-prettier добавляет вычислительную нагрузку:

  • каждый файл проходит через Prettier
  • выполняется diff сравнение

Особенности:

  • в больших проектах линтинг может замедляться
  • особенно заметно при CI-проверках
  • кеширование ESLint частично снижает нагрузку

Кеширование ESLint

Для оптимизации используется:

eslint . --cache

Кеширование позволяет:

  • не перерасчитывать неизмененные файлы
  • ускорять повторные проверки

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

В монорепозиториях важно учитывать:

  • единый Prettier config
  • синхронизацию ESLint конфигураций
  • исключение конфликтов между пакетами

Типичная структура:

/packages
  /app
  /ui
.eslintrc.json
.prettierrc

eslint-plugin-prettier работает централизованно через общую конфигурацию.

Работа с TypeScript

В TypeScript-проектах плагин работает через ESLint-парсер:

{
  "parser": "@typescript-eslint/parser",
  "plugins": ["prettier"],
  "extends": ["plugin:prettier/recommended"]
}

Prettier форматирует:

  • типы
  • интерфейсы
  • дженерики
  • импорт/экспорт структуры

ESLint фиксирует отклонения независимо от синтаксиса TS.

Интеграция с React и JSX

В React-проектах Prettier внутри ESLint обрабатывает JSX:

const Button = ({onClick})=><button onCl ick={onClick}>Click</button>

После проверки:

const Button = ({ onClick }) => (
  <button onCl ick={onClick}>Click</button>
);

ESLint фиксирует формат JSX как часть правила Prettier.

Ограничения подхода

Использование Prettier как ESLint-правила имеет особенности:

  • увеличение времени анализа
  • невозможность независимого запуска Prettier без ESLint
  • менее гибкое разделение форматирования и линтинга
  • сложнее диагностировать чисто форматные проблемы вне ESLint

Когда использование оправдано

Подход особенно эффективен в сценариях:

  • единый стандарт кодстайла в команде
  • CI/CD, где нужен один инструмент проверки
  • проекты с жесткой дисциплиной форматирования
  • необходимость минимизации ручных шагов в пайплайне разработки
Оглавление