Как настроить ESLint и Prettier в проекте раз и навсегда

Введение

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

В этой статье разберём, как настроить ESLint и Prettier один раз так, чтобы они работали в связке без конфликтов, автоматически форматировали код при сохранении и блокировали коммиты с нарушениями. Подход универсален для React, Next.js, Node.js и любых других проектов на JS/TS.

Установка зависимостей

Для старта установим базовый набор пакетов. Если используете TypeScript, добавьте парсер и плагин для него.

npm install --save-dev eslint prettier \
  eslint-config-prettier \
  @typescript-eslint/parser \
  @typescript-eslint/eslint-plugin

Ключевой пакет здесь — eslint-config-prettier. Он отключает все правила ESLint, которые конфликтуют с Prettier. Раньше многие использовали eslint-plugin-prettier, чтобы запускать Prettier как правило ESLint, но сейчас официальная документация Prettier рекомендует этого избегать: подсветка ошибок форматирования замусоривает редактор и замедляет линтинг.

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

С ESLint 9 по умолчанию используется flat config — файл eslint.config.js в корне проекта. Создадим минимальный, но рабочий конфиг для TypeScript-проекта.

// eslint.config.js
import js from '@eslint/js';
import tseslint from 'typescript-eslint';
import prettier from 'eslint-config-prettier';

export default [
  // базовые рекомендации ESLint
  js.configs.recommended,
  // рекомендации для TypeScript
  ...tseslint.configs.recommended,
  // отключаем правила, конфликтующие с Prettier (всегда последним)
  prettier,
  {
    rules: {
      // запрещаем console.log, но разрешаем warn и error
      'no-console': ['warn', { allow: ['warn', 'error'] }],
      // неиспользуемые переменные с префиксом _ игнорируем
      '@typescript-eslint/no-unused-vars': [
        'error',
        { argsIgnorePattern: '^_', varsIgnorePattern: '^_' },
      ],
    },
  },
];

Важный момент: prettier из eslint-config-prettier должен идти последним в массиве. Только так он сможет отключить конфликтующие правила, добавленные другими конфигами выше.

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

Prettier настраивается отдельно, через файл .prettierrc или prettier.config.js. Конфиг намеренно минималистичен — у Prettier мало настроек, и это его философия.

// prettier.config.js
export default {
  // одинарные кавычки вместо двойных
  semi: true,
  singleQuote: true,
  // длина строки до переноса
  printWidth: 100,
  // 2 пробела для отступа
  tabWidth: 2,
  // запятая после последнего элемента в объектах и массивах
  trailingComma: 'all',
  // перенос стрелочных функций с одним аргументом
  arrowParens: 'always',
};

Не забудьте про .prettierignore — он работает по тем же правилам, что и .gitignore.

node_modules
dist
build
coverage
.next

Скрипты в package.json

Добавим команды для запуска линтера и форматтера в package.json. Это пригодится и локально, и в CI.

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}

format:check особенно удобен в CI: команда не меняет файлы, а только возвращает ненулевой код выхода, если форматирование нарушено.

Интеграция с VS Code

Чтобы код форматировался автоматически при сохранении, добавьте в проект файл .vscode/settings.json. Он переопределит пользовательские настройки только для этого репозитория — никаких сюрпризов для команды.

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

Теперь при каждом сохранении файла Prettier форматирует код, а ESLint автоматически фиксит правила, которые умеет чинить.

Pre-commit хуки через Husky и lint-staged

Даже с автоформатированием в редакторе кто-то закоммитит непроверенный код. Решение — запускать линтер на staged-файлах перед коммитом.

npm install --save-dev husky lint-staged
npx husky init

В package.json добавим конфиг lint-staged, который обработает только изменённые файлы — это быстро даже на больших проектах.

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,md,css}": [
      "prettier --write"
    ]
  }
}

Затем в .husky/pre-commit пропишем запуск npx lint-staged. После этого ни один невалидный коммит не пройдёт.

Частые ошибки

Plugin Prettier внутри ESLint. Связка eslint-plugin-prettier и plugin:prettier/recommended создаёт шум в редакторе: каждая лишняя запятая подсвечивается как ошибка линтера. Используйте только eslint-config-prettier.

Конфиг Prettier не последний. Если поставить prettier в середине массива конфигов ESLint, последующие конфиги могут вернуть конфликтующие правила. Правило простое — всегда последним.

Разные версии в monorepo. В монорепозитории легко получить разные версии ESLint в пакетах. Выносите все linting-зависимости в корневой package.json и используйте workspaces.

Игнорирование .prettierignore. Без него Prettier попытается форматировать сгенерированные файлы, lock-файлы и содержимое node_modules. Это медленно и иногда ломает сборку.

Отключение правил по одному. Если приходится писать // eslint-disable-next-line в каждом втором файле — пересмотрите конфиг. Скорее всего, правило просто не подходит проекту.

Заключение

Правильная связка ESLint и Prettier настраивается за полчаса, но окупается на всём жизненном цикле проекта. ESLint берёт на себя качество кода, Prettier — единый стиль, eslint-config-prettier устраняет конфликты, VS Code форматирует при сохранении, а Husky с lint-staged защищают репозиторий от грязных коммитов.

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