Єдиний стиль коду з EditorConfig: налаштування під ключ
Уявіть: у команді п'ять розробників, кожен використовує свій редактор — VS Code, WebStorm, Vim. Один ставить відступи пробілами, інший табами. При коміті git показує сотні змін через заміну пробілів на таби. Витрачаються години на узгодження та правку. В одному реальному проєкті з командою з 8 осіб ми впровадили EditorConfig — і кількість конфліктів у git скоротилася на 95%. Файл .editorconfig у корені проєкту задає єдині правила для всіх редакторів: відступи, закінчення рядків, кодування та trailing whitespace. Більше жодних суперечок про форматування. EditorConfig підтримується з коробки у VS Code, JetBrains IDE, Vim, Emacs, Sublime Text. Для інших — плагін, який є практично для будь-якого редактора. Налаштування займає від 1 до 4 годин і окупається за перший тиждень за рахунок скорочення часу на код-рев'ю.
Як EditorConfig вирішує проблему розбіжностей у стилі коду?
EditorConfig діє на рівні редактора: при відкритті файлу він автоматично застосовує задані налаштування. Це означає:
- Всі розробники бачать код з однаковими відступами.
- Нові файли створюються з правильним закінченням рядків (LF).
- Фінальний перевід рядка додається автоматично.
- Trailing whitespace видаляється при збереженні.
Ми налаштовуємо EditorConfig під конкретний стек проєкту. Наприклад, для проєктів на JavaScript використовуємо indent_size = 2, для Python — indent_size = 4, для Go — таби. Нижче приклад типового конфігу:
# EditorConfig root = true [*] charset = utf-8 end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true indent_style = space indent_size = 2 [*.{js,jsx,ts,tsx,mjs,cjs}] indent_style = space indent_size = 2 max_line_length = 100 [*.{css,scss,less,styl}] indent_style = space indent_size = 2 [*.{html,htm}] indent_style = space indent_size = 2 [*.json] indent_style = space indent_size = 2 [*.{yml,yaml}] indent_style = space indent_size = 2 [*.py] indent_style = space indent_size = 4 max_line_length = 88 [*.go] indent_style = tab indent_size = 4 [*.php] indent_style = space indent_size = 4 [Makefile] indent_style = tab [*.md] trim_trailing_whitespace = false max_line_length = off [*.{png,jpg,jpeg,gif,ico,webp,svg,woff,woff2,eot,ttf,otf,mp4,mp3,pdf,zip}] insert_final_newline = false trim_trailing_whitespace = false Перевірка застосування та інтеграція з CI
EditorConfig сам не форматує існуючі файли. Щоб перевірити та автоматично виправити порушення, використовуємо editorconfig-checker:
npm install --save-dev editorconfig-checker npx ec src/ Додаємо перевірку в CI:
{ "scripts": { "lint:editorconfig": "editorconfig-checker" } } Винятки налаштовуємо в .ecrc:
{ "Exclude": [ "dist", "node_modules", ".git", "*.min.js", "*.min.css" ], "ExcludeRegex": "vendor/.*" } Що входить у налаштування EditorConfig?
Ми надаємо повний пакет: файл .editorconfig з правилами під ваш стек, налаштування IDE (до 3 редакторів), інтеграцію з Prettier та CI, виправлення існуючих файлів та навчання команди за 15 хвилин.
Чому варто довірити налаштування професіоналам?
У нас за плечима більше 5 років досвіду у веб-розробці. Ми налаштували EditorConfig для 50+ проєктів — від невеликих лендінгів до великих SaaS. Гарантуємо: після налаштування 99% конфліктів форматування зникають. Передаємо готовий конфіг, перевірочний скрипт та документацію.
Процес нашої роботи
- Аналіз проєкту — визначаємо використовувані мови, фреймворки, поточні конфлікти форматування.
- Створення
.editorconfig— пишемо правила під ваш стек, включаючи рідкісні мови. - Налаштування IDE — конфігуруємо VS Code (або інші редактори) для автоматичного застосування.
- Інтеграція з Prettier/ESLint — узгоджуємо налаштування, щоб вони не суперечили одне одному.
- Перевірка та виправлення — запускаємо
editorconfig-checker --fixна всьому проєкті, виправляємо знайдені порушення. - Додавання в CI — налаштовуємо перевірку при кожному коміті.
- Передача результатів — віддаємо готовий
.editorconfig, документацію, навчання команди (15 хвилин).
Терміни та вартість
Налаштування Basic (тільки створення файлу та перевірка) — від 1 години. Full (включаючи інтеграцію з CI, виправлення існуючих файлів, навчання) — від 4 годин. Вартість розраховується індивідуально в залежності від розміру проєкту та кількості мов. Зв'яжіться з нами — оцінимо ваш проєкт безкоштовно.
EditorConfig vs Prettier vs ESLint: порівняння
| Інструмент | Що контролює | Застосування | Пріоритет |
|---|---|---|---|
| EditorConfig | Відступи, закінчення рядків, кодування | При відкритті файлу в IDE | Базовий (редактор) |
| Prettier | Форматування коду (дужки, крапки з комою, перенесення) | При збереженні файлу (on save) | Форматувальник |
| ESLint | Якість та стиль коду (правила, best practices) | При лінтингу або збереженні | Лінтер (правила) |
EditorConfig простіше в налаштуванні: один файл, немає залежностей. Але він не форматує код — для цього потрібен Prettier. Рекомендуємо використовувати EditorConfig як основу, а Prettier — для форматування.
Типові помилки при самостійному налаштуванні
| Помилка | Наслідок | Рішення |
|---|---|---|
Не вказано root = true |
EditorConfig може застосувати правила з батьківської директорії, ламаючи структуру | Завжди вказувати root = true у кореневому конфігу |
| Забули про Makefile | У Makefile обов'язкові таби, інакше збірка впаде | Додати правило для Makefile: [Makefile] indent_style = tab |
| Невідповідність з Prettier | Конфлікти між indent_size в EditorConfig та tabWidth в Prettier |
Узгодити значення: наприклад, обидва 2 або 4 |
| Не виключені бінарні файли | EditorConfig спробує додати final newline до зображень, пошкоджуючи їх | Виключити бінарні розширення в конфігу |
Ми враховуємо всі ці нюанси та гарантуємо єдиний стандарт. Замовте налаштування прямо зараз — це заощадить вашій команді до 2 годин на тиждень на код-рев'ю. Отримайте консультацію щодо поточної конфігурації.







