В проектах с JavaScript и TypeScript линтинг с помощью ESLint часто становится одной из самых затратных операций в цепочке CI/CD и локальной разработки. По мере роста кодовой базы проверка всего проекта на каждый коммит или запуск пайплайна приводит к увеличению времени ожидания и снижению эффективности разработки. Оптимизация достигается за счёт выполнения линтинга только над изменёнными файлами, что реализуется через связку Git hooks и утилиты lint-staged.
lint-staged выполняет фильтрацию файлов, добавленных в staging area Git, и запускает заданные команды только над этим набором. В сочетании с ESLint это позволяет проверять строго ограниченный набор файлов перед коммитом, не затрагивая всю кодовую базу.
Git разделяет состояние файлов на несколько зон:
lint-staged использует именно staging area как источник правды. В неё
попадают файлы после выполнения git add. Такой подход
обеспечивает детерминированность: проверяются только те изменения,
которые фактически планируются к коммиту.
Ключевой принцип:
линтинг выполняется только над файлами, находящимися в индексе Git
lint-staged представляет собой оркестратор команд, который:
Типичный сценарий взаимодействия с ESLint:
.js, .ts,
.jsx, .tsxeslint --fixОсновная схема интеграции строится вокруг автоматического запуска ESLint перед коммитом.
В типичном проекте используется следующая связка:
{
"lint-staged": {
"*.{js,jsx,ts,tsx}": [
"eslint --fix",
"git add"
]
}
}В этом случае все staged-файлы с указанными расширениями проходят через ESLint, после чего автоматически возвращаются в индекс, если были изменены.
Файл .lintstagedrc.js:
module.exports = {
"*.{js,jsx,ts,tsx}": [
"eslint --fix",
"git add"
]
};Использование JS-конфига позволяет динамически изменять поведение, подключать условия и переиспользовать логику.
lint-staged не работает самостоятельно в контексте Git событий. Для
автоматического запуска используется Husky, который подключает hook
pre-commit.
npx husky installДобавление hook:
npx husky add .husky/pre-commit "npx lint-staged"Механика работы:
ESLint в данном сценарии чаще всего запускается с флагом:
--fix — автоматическое исправление проблемКоманда:
eslint --fix file.jsОсобенности поведения:
git addlint-staged использует glob patterns для маршрутизации файлов.
Примеры:
"*.{js,ts}": "eslint --fix"{
"*.{js,ts}": "eslint --fix",
"*.{css,scss}": "stylelint --fix",
"*.{json,md}": "prettier --write"
}Такая структура позволяет комбинировать разные инструменты линтинга в одном pre-commit процессе.
Основное преимущество lint-staged заключается в сокращении объёма обрабатываемых данных.
Ключевой эффект:
снижение времени pre-commit с секунд до миллисекундного диапазона в небольших изменениях
После выполнения ESLint с --fix возможна модификация
файлов. lint-staged автоматически управляет этим через:
git addили встроенную опцию --stash/--diff
режимов.
Без повторного добавления изменения не попадут в commit, что приведёт к рассинхронизации состояния.
Если ESLint возвращает ненулевой код выхода:
Это обеспечивает механизм предотвращения попадания невалидного кода в репозиторий.
В монорепозиториях (npm workspaces, Turborepo, Nx) lint-staged применяется к локально изменённым пакетам.
Особенности:
Пример структуры:
{
"packages/*/*.{js,ts}": "eslint --fix"
}Часто ESLint используется совместно с Prettier, где задачи разделяются:
Конфигурация lint-staged:
{
"*.{js,ts}": [
"eslint --fix",
"prettier --write"
]
}Порядок выполнения критичен: ESLint выполняется до форматирования, чтобы избежать конфликтов правил.
Для ускорения обработки применяется ESLint cache:
eslint --fix --cacheФайл .eslintcache позволяет:
Однако в связке с staged-файлами кэш даёт меньший эффект, так как набор файлов уже ограничен Git.
Если часть файлов не попала в staging, возникает несогласованность стиля между коммитами.
Одновременное использование ESLint и Prettier без согласованной конфигурации приводит к циклическим изменениям файлов.
Включение неподходящих файлов в glob (например, build artifacts) увеличивает время обработки.
При отсутствии Husky или аналогов lint-staged не запускается автоматически, что снижает эффективность контроля качества.
lint-staged ориентирован на локальные pre-commit проверки, однако может использоваться в CI с адаптацией:
Однако основная ценность сохраняется именно в локальной разработке, где важно минимизировать задержки перед коммитом.
Типовая последовательность внедрения:
--fix для автоматических исправленийРезультатом становится система контроля качества, встроенная в процесс коммита, работающая исключительно с изменёнными файлами и минимизирующая избыточные вычисления.