Як автоматичне форматування рятує код-рев’ю
Кожен другий PR у JavaScript/TypeScript-проєктах містить суперечки про стиль коду — відступи, лапки, крапки з комою. Розробники витрачають до 20% часу код-рев’ю лише на обговорення форматування. Це не лише сповільнює поставку, а й демотивує команду. Ми впроваджуємо автоматичний фікс при кожному коміті через Husky та lint-staged, і проблема зникає. В одному проєкті на React + TypeScript з командою з 5 осіб час рев’ю скоротився з 40 хвилин до 15, а кількість конфліктів злиття знизилась на 30%. Типова помилка — налаштовувати форматування локально, але забувати інтегрувати в CI. Це призводить до того, що код у репозиторії не відповідає стандартам. Ми одразу включаємо перевірки в CI/CD, щоб гарантувати єдиний стиль на всіх етапах. Середня економія часу команди з 5 осіб — 8 людино-годин на тиждень. Замовте налаштування та позбавтесь рутини. Отримайте безкоштовну оцінку вашого проєкту протягом дня.
Чому автоматичне форматування при коміті необхідне?
Без автоматизації кожен розробник використовує свої налаштування форматування. В результаті код у різних гілках відрізняється, а merge request’и перетворюються на обговорення відступів. Автоматичний фікс при коміті вирішує цю проблему на корені: код завжди приводиться до єдиного стандарту перед записом у репозиторій. Це знижує когнітивне навантаження на рев’юверів і прискорює інтеграцію змін.
Як налаштувати Prettier та ESLint за 30 хвилин?
Для JavaScript/TypeScript-проєктів стандарт — зв’язка Prettier (форматування) та ESLint (якість коду). Встановлення:
npm install --save-dev prettier eslint Створіть файли конфігурації .prettierrc та .eslintrc.js. Для автоматичного запуску при коміті використовуйте Husky та lint-staged:
npm install --save-dev husky lint-staged npx husky init У package.json додайте:
{ "lint-staged": { "*.{js,ts,jsx,tsx}": ["eslint --fix", "prettier --write"], "*.{css,scss,md,json,yaml}": ["prettier --write"] } } Офіційна документація Husky рекомендує також додати хук commit-msg для перевірки повідомлень комітів.
Чому lint-staged кращий за повну перевірку проєкту?
lint-staged обробляє лише staged (індексовані) файли. Це критично для швидкості: при коміті не перевіряється весь проєкт, а лише змінені файли. Повна перевірка може займати хвилини, lint-staged — секунди. У великому монорепозиторії з 500+ файлами повний прогін ESLint триває 3–4 хвилини, а lint-staged — менше 5 секунд. Ми наполегливо рекомендуємо цей підхід.
Порівняння форматувальників для різних мов
| Мова | Інструмент | Мета | Конфігурація |
|---|---|---|---|
| JavaScript/TypeScript | Prettier | Форматування | .prettierrc |
| JavaScript/TypeScript | ESLint | Якість коду | .eslintrc.* |
| Python | Black | Форматування (zero-config) | pyproject.toml |
| Python | Ruff | Лінтінг + форматування | pyproject.toml |
| PHP | PHP CS Fixer / Pint | Форматування | .php-cs-fixer.dist.php |
| Go | gofmt | Стандартний формат | Вбудований у мову |
Універсальне рішення — pre-commit framework
Для Python-проєктів або змішаних репозиторіїв використовуйте pre-commit. Приклад конфігу:
# .pre-commit-config.yaml repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.6.0 hooks: - id: trailing-whitespace - id: end-of-file-fixer - id: check-yaml - repo: https://github.com/psf/black rev: 24.4.2 hooks: - id: black - repo: https://github.com/astral-sh/ruff-pre-commit rev: v0.4.0 hooks: - id: ruff args: [--fix] Встановіть хуки: pip install pre-commit та pre-commit install. Підтримується понад 1000 готових хуків для будь-яких мов.
Інтеграція з CI: покрокова інструкція
Щоб гарантувати дотримання стандартів навіть при обході локальних хуків, додайте перевірки в CI.
- Створіть файл
.github/workflows/lint.yml(для GitHub Actions). - Додайте крок встановлення залежностей:
npm ciабоpip install -r requirements.txt. - Додайте кроки запуску форматування та лінтингу:
npx prettier --check .таnpx eslint .. - Для Python:
black --check .таruff check .. - Запуште зміни в репозиторій — тепер кожен PR буде перевірятися автоматично.
Це займає 1–2 години налаштування і повністю виключає можливість потрапляння невідформатованого коду в master.
Як гарантувати дотримання стандартів, незважаючи на обхід локальних хуків?
Локальні хуки можна обійти флагом --no-verify. Єдиний надійний спосіб — перевірки в CI. Налаштування CI-пайплайну займає годину і дає стовідсоткову гарантію, що код у master відповідає стандартам. Після впровадження CI в одному проєкті кількість обходів скоротилася з 40% до нуля. Замовте послугу — ми налаштуємо CI за 1–2 години.
Порівняння часу налаштування для різних стеків
| Стек | Інструменти | Час налаштування |
|---|---|---|
| JavaScript/TypeScript | Husky + lint-staged + Prettier + ESLint | 2–4 години |
| Python | pre-commit + Black + Ruff | 2–3 години |
| PHP | pre-commit + PHP CS Fixer / Pint | 2–3 години |
| Go | pre-commit + gofmt | 1–2 години |
Що входить у роботу та строки
При замовленні налаштування автоматичного форматування ми надаємо:
- Налаштування Husky, lint-staged, Prettier, ESLint під ваш стек
- Конфігурацію pre-commit для Python/PHP/Go проєктів
- Інтеграцію перевірок у GitHub Actions або GitLab CI
- Документацію для команди (як додати нову мову)
- Підтримку протягом місяця після налаштування
Строки: налаштування для однієї мови — 2–4 години, інтеграція з CI — 1–2 години. Ми автоматизували складання та деплой у 50+ проєктах, і в кожному випадку виключили суперечки про стиль коду. В одному Python-проєкті на Django впровадження pre-commit та CI зайняло 3 години, після чого жоден коміт з порушенням стилю не потрапив у master. Замовте налаштування автоматичного форматування — ваша команда перестане витрачати час на обговорення відступів. Отримайте безкоштовну консультацію та оцінку вашого проєкту протягом дня.