ESLint и Prettier: настройка проекта

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

Зачем использовать ESLint и Prettier вместе

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

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

Какие пакеты понадобятся

Ниже — минимальный набор для типичного проекта на JavaScript. Для TypeScript и React добавляются дополнительные пакеты, о них расскажу в соответствующем подразделе.

Пакет	Назначение
eslint	Ядро линтера
prettier	Форматирование кода
eslint-config-prettier	Отключает правила ESLint, конфликтующие с Prettier
eslint-plugin-prettier	Запускает Prettier как правило ESLint (опционально)
husky, lint-staged	Запуск форматирования/линтинга при коммите

Этот набор покрывает базовые случаи. Для TypeScript нужны @typescript-eslint/parser и @typescript-eslint/eslint-plugin. Для React полезен eslint-plugin-react и настройки JSX.

Пошаговая настройка для JavaScript-проекта

Покажу простой сценарий установки с npm. Аналогично работает yarn. Начинаем в корне проекта.

Установите основные пакеты:

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

Создайте базовые конфигурационные файлы. Пример .eslintrc.cjs:

module.exports = {
  env: { browser: true, es2021: true, node: true },
  extends: ['eslint:recommended', 'plugin:prettier/recommended'],
  parserOptions: { ecmaVersion: 12, sourceType: 'module' },
  rules: {
    // ваши правила
  },
};

Файл .prettierrc.json может содержать настройки форматирования:

{
  "printWidth": 100,
  "tabWidth": 2,
  "singleQuote": true,
  "trailingComma": "all"
}

Важно: плагин plugin:prettier/recommended включает eslint-plugin-prettier и eslint-config-prettier, что отключает конфликтные правила и запускает Prettier как правило ESLint. Это удобный вариант для большинства проектов.

Игровая дорожка скриптов

Добавьте в package.json скрипты для удобства:

"scripts": {
  "lint": "eslint . --ext .js,.jsx",
  "format": "prettier --write "src/**/*.{js,jsx,json,css,md}"",
  "prepare": "husky install"
}

Теперь можно вручную запускать npm run lint и npm run format. Для автоматической проверки при коммите используйте husky и lint-staged, о них ниже.

Дополнения для TypeScript и React

TypeScript требует отдельного парсера и набора правил. Это несложно, но нужно помнить про порядок расширений в extends и корректную настройку parserOptions.

Необходимые зависимости:

@typescript-eslint/parser
@typescript-eslint/eslint-plugin
eslint-plugin-react (для проектов с JSX)

Пример .eslintrc.cjs для TypeScript + React:

module.exports = {
  parser: '@typescript-eslint/parser',
  env: { browser: true, es2021: true },
  extends: [
    'eslint:recommended',
    'plugin:react/recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:prettier/recommended'
  ],
  parserOptions: {
    ecmaFeatures: { jsx: true },
    project: './tsconfig.json',
    sourceType: 'module'
  },
  settings: { react: { version: 'detect' } },
  rules: {
    // добавьте желаемые правила
  }
};

Обратите внимание на порядок: сначала правила ESLint и плагинов, затем интеграция Prettier в самом конце, чтобы отключить конфликтующие правила.

Интеграция в редактор и CI

Чтобы команда не спорила о форматировании, настроим автоматическое применение правил в редакторе и в системе непрерывной интеграции. Для VSCode достаточно установить расширения ESLint и Prettier, а затем включить форматирование при сохранении.

Пример настроек VSCode в settings.json:

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "eslint.format.enable": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

В CI нужно запускать lint и fail-пайплайн, если есть ошибки, и при желании — отдельный шаг format-check, который проверяет, что код отформатирован:

npm run lint
npm run format -- --check

Для командной работы полезно настроить husky + lint-staged, чтобы формат и автофикс запускались перед коммитом:

npm install --save-dev husky lint-staged
npx husky install
# в package.json
"lint-staged": {
  "src/**/*.{js,jsx,ts,tsx}": [
    "prettier --write",
    "eslint --fix",
    "git add"
  ]
}

Типичные конфликты и способы их разрешения

Чаще всего возникают споры о кавычках, запятых и отступах. Решение простое: дать Prettier полномочия на все форматирование и отключить соответствующие правила ESLint. Это делает eslint-config-prettier.

Еще одна проблема — дублирование функционала: если использовать eslint-plugin-prettier, Prettier запускается как правило ESLint, и вы видите форматерные ошибки в выводе ESLint. Это удобно, но может замедлять процесс линтинга в больших проектах. Можно вместо плагина запускать Prettier отдельно командой format.

Для TypeScript важно не забывать про parserOptions.project. Без него некоторые правила @typescript-eslint не работают корректно. Также при миграции большого кода советую включать строгие правила постепенно, иначе команда может столкнуться с потоком мелких исправлений.

Практические советы из реальной работы

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

Еще одна ситуация: при включении eslint-plugin-prettier CI начал падать у половины разработчиков. Оказалось, что локальные редакторы форматировали код иначе. Решение — унифицировать настройки редактора и добавить форматирование в pre-commit, тогда локальные отличия исчезают.

Чеклист для быстрой проверки перед релизом

Ниже список действий, которые стоит проделать, чтобы проект был в порядке и новые члены команды не теряли время на настройку.

Добавить в репозиторий .eslintrc и .prettierrc с базовыми настройками.
Установить husky и lint-staged для форматирования и автофикса при коммите.
Настроить CI на запуск lint и проверку форматирования.
Обновить README с инструкцией запуска lint и format.
При миграции большого кода использовать —fix и поэтапное ужесточение правил.

Настройка ESLint и Prettier — не магия, а набор простых правил и привычек. Отдавайте форматирование Prettier, делегируйте ESLint семантические и архитектурные проверки, обязательно интегрируйте инструменты в workflow команды. Это снизит шум в код-ревью и позволит сосредоточиться на действительно важных вещах.

ESLint и Prettier: настройка проекта, которая не будет мешать работать