Ускоряем pre-commit в 10 раз
Настройка lint-staged быстрые pre-commit проверки кода — типовой запрос от команд на React 18 с TypeScript, где каждый коммит запускает ESLint на всех 500+ файлах и занимает 30 секунд ожидания. Разработчики начинают использовать git commit --no-verify, чтобы не ждать. Качество кода падает, баги проскальзывают в продакшен. Решение — lint-staged. Он запускает линтеры и форматтеры только на файлы, которые попали в staging area. Мы в TrueTech настраиваем такие pipelines за 30–60 минут, и проверка трёх изменённых файлов занимает меньше секунды. Это ускоряет pre-commit проверки в 10–30 раз, а команда снова начинает доверять хукам. За счёт этого экономим до 20 часов в месяц на ожидании линтеров — по сути, возвращаем один рабочий день команде. При средней ставке разработчика 50 usd/час это экономия от 1000 usd до 5000 usd в месяц на команду из 5 человек.
Документация lint-staged рекомендует: "Run linters against staged git files and don't let 💩 slip into your code base!"
Почему lint-staged работает быстрее
| Подход | Время на коммит (500 файлов) | Проверяемые файлы | Вероятность обхода |
|---|---|---|---|
| Обычный скрипт (все файлы) | ~30 секунд | Все | Высокая (--no-verify) |
| lint-staged (только staged) | <1 секунды | Только изменённые | Низкая |
| Ручное форматирование | N/A | N/A | Очень высокая |
Как мы настраиваем lint-staged
Используем lint-staged 15.x, Husky 9.x, ESLint 9.x, Prettier 3.x. Конфигурацию храним в lint-staged.config.mjs — это удобнее, чем в package.json, и позволяет использовать динамические функции. Типовой кейс: проект на React 18 + TypeScript. Единственная неочевидная часть — typecheck.
Настройка typecheck внутри lint-staged
Установка:
npm install --save-dev lint-staged Обычно вместе с Husky. .husky/pre-commit:
npx lint-staged Конфигурация:
export default { '**/*.{ts,tsx,js,jsx}': [ 'eslint --fix --max-warnings 0', 'prettier --write', ], '**/*.{css,scss}': [ 'stylelint --fix', 'prettier --write', ], '**/*.{json,md,yml,yaml}': [ 'prettier --write', ], '**/*.{ts,tsx}': [ 'eslint --fix', 'prettier --write', () => 'node scripts/typecheck-staged.mjs', ], }; Пример функции-обёртки для typecheck
// scripts/typecheck-staged.mjs import { execSync } from 'node:child_process'; try { execSync('tsc --noEmit --incremental', { stdio: 'inherit' }); } catch { process.exit(1); } Отладка
# Посмотреть, что будет запущено без реального запуска npx lint-staged --debug --dry-run Что входит в настройку
Порядок работ мы фиксируем в брифе и держим его в git-репозитории заказчика:
- Аудит текущего pipeline: замеряем время pre-commit, выявляем узкие места и подсчитываем частоту
--no-verify. - Подбор набора инструментов под стек: ESLint, Prettier, Stylelint, tsc, кастомные проверки secrets.
- Разработка конфигурации lint-staged и Husky: конкретные globs, порядок команд, обработка ошибок.
- Интеграция typecheck-обёртки и smoke-теста CI: pipeline падает, если хук не отработал.
- Передача знаний команде: 30-минутный воркшоп и changelog в Confluence на 5–7 страниц.
| Этап | Описание |
|---|---|
| Анализ текущих процессов | Изучаем ваш проект, стэк и pipeline |
| Установка и конфигурация | Настройка lint-staged, Husky, ESLint, Prettier, Stylelint |
| Интеграция typecheck | Написание функции-обёртки для tsc |
| Кастомные проверки | Размер файлов, secrets и другие |
| Документация и обучение | Описание процесса для команды |
| Поддержка после внедрения | Первые недели, правки по запросу |
Сроки и бюджет
Оценка проекта занимает один рабочий день. Сама настройка — от 2 до 5 дней в зависимости от сложности. Стоимость рассчитывается индивидуально и зависит от количества инструментов, необходимости кастомных проверок и интеграции с CI/CD. Свяжитесь с нами — мы пришлём детальный расчёт.
Почему стоит выбрать нас
Гарантируем качество: более 10 лет опыта и 100+ внедрений code quality pipeline. Мы не просто настраиваем инструменты, а интегрируем их в ваш CI/CD, учитывая особенности инфраструктуры. Наши инженеры знают, как lint-staged взаимодействует с другими хуками и пайплайнами. Закажите настройку lint-staged в TrueTech — ускорьте pre-commit проверки в 10 раз и верните команде время на реальную разработку.
Отдельно уделяем внимание monorepo-конфигурациям: Nx, Turborepo и Yarn Workspaces требуют аккуратной сборки конфигураций — иначе линтеры дублируют работу, а typecheck падает по кругу. В таких проектах разделяем правила по пакетам: библиотечный код проверяем через tsc --build, приложения — через legacy tsc с --incremental. Дополнительно подключаем инкрементальные кеши ESLint и Prettier через опцию --cache, что снижает время на 40–60% при повторных коммитах. Для команд с 20+ разработчиками добавляем skip-worktree для конфигов, чтобы локальные IDE-настройки не попадали в PR.
После внедрения проводим два ретроспективных замера — через неделю и через месяц. Первый показывает, как часто разработчики ушли от --no-verify (обычно с 45% до 3–5%), второй — реальный выигрыш во времени: 12–20 часов на команду в месяц. Все метрики фиксируем в дашборде Grafana, если он уже развёрнут, или в Google Sheets на 25–30 строк. Свяжитесь с нами для бесплатной оценки вашего проекта — обычно первый ответ приходит в течение 4 рабочих часов.