Editorconfig

.editorconfig задаёт единые правила форматирования исходного кода на уровне файловой системы, независимо от используемого редактора, IDE или операционной системы. В Vite-проектах он не является обязательным элементом сборки, но играет важную роль в унификации стиля кода до того, как вступают в работу инструменты уровня ESLint или Prettier.

Основная задача заключается в устранении различий между редакторами: разные настройки табуляции, кодировок, символов конца строки и поведения при сохранении файлов. Это особенно важно в проектах на Vite, где часто используются смешанные технологии: JavaScript, TypeScript, Vue, React, CSS, JSON.

Структура файла .editorconfig

Файл .editorconfig располагается в корне проекта и имеет INI-подобный синтаксис. Он может содержать несколько секций, каждая из которых применяется к определённому набору файлов.

Базовая структура выглядит следующим образом:

root = true

[*]
charset = utf-8
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

Логика применения секций

Каждый блок начинается с шаблона файлов:

  • [*] — все файлы проекта
  • [*.js] — только JavaScript
  • [*.vue] — Vue компоненты
  • [*.css] — стили
  • [*.md] — Markdown документация

Правила применяются по приоритету: более специфичные секции перекрывают общие.

Основные параметры конфигурации

charset

Определяет кодировку файлов.

charset = utf-8

UTF-8 является стандартом для современных Vite-проектов, особенно при использовании международных библиотек и фреймворков.

indent_style и indent_size

Контролируют стиль отступов:

indent_style = space
indent_size = 2

В большинстве JavaScript-экосистем, включая Vue и React проекты на Vite, используется 2 пробела.

Для некоторых файлов допускается переопределение:

[*.md]
indent_size = 4

end_of_line

Определяет символ конца строки:

end_of_line = lf

LF используется как стандарт в кроссплатформенных проектах. CRLF может приводить к конфликтам в git и CI.

insert_final_newline

Добавляет пустую строку в конце файла:

insert_final_newline = true

Это снижает количество диффов в системах контроля версий и соответствует POSIX-стилю.

trim_trailing_whitespace

Удаляет пробелы в конце строк:

trim_trailing_whitespace = true

Особенно важно для Markdown и JavaScript файлов, где случайные пробелы создают шум в diff.

Пример .editorconfig для Vite-проекта

Типичный файл для проекта на Vite с использованием JavaScript или TypeScript:

root = true

[*]
charset = utf-8
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

[*.md]
trim_trailing_whitespace = false
insert_final_newline = false

[*.{json,yml,yaml}]
indent_size = 2

[*.css]
indent_size = 2

[*.html]
indent_size = 2

Такая конфигурация обеспечивает единообразие между слоями приложения: frontend-код, конфигурационные файлы, документация.

Интеграция с Vite и инструментами сборки

Vite сам по себе не обрабатывает .editorconfig, но экосистема вокруг него активно использует его как базовый слой форматирования.

Роль в пайплайне разработки

.editorconfig работает до этапа:

  • линтинга (ESLint)
  • форматирования (Prettier)
  • сборки (Vite dev server / build)

Таким образом, он задаёт фундаментальные правила, которые не должны зависеть от плагинов или конфигураций проекта.

Влияние на Vite plugins

Плагины Vite (например, для Vue, React, PostCSS) не читают .editorconfig напрямую, но корректная настройка уменьшает количество конфликтов при трансформации файлов, особенно в случаях:

  • автоформатирования SFC (Single File Components)
  • генерации временных файлов
  • HMR (Hot Module Replacement)

Взаимодействие с Prettier и ESLint

.editorconfig часто используется совместно с Prettier и ESLint, но между ними существует различие уровней ответственности.

Разделение зон ответственности

  • .editorconfig: базовые правила текста (отступы, переводы строк)
  • Prettier: форматирование синтаксиса (скобки, кавычки, переносы)
  • ESLint: качество кода и логические ошибки

Конфликты конфигураций

Частая проблема — дублирование настроек:

// prettier.config.js
{
  "tabWidth": 2,
  "useTabs": false
}
# .editorconfig
indent_style = space
indent_size = 2

При несовпадении настроек может возникать эффект “переформатирования при сохранении”. Обычно Prettier считается приоритетным, а .editorconfig служит согласующим слоем для редакторов.

Рекомендованная стратегия

  • .editorconfig задаёт минимальные стандарты
  • Prettier переопределяет стиль вывода
  • ESLint контролирует семантику

Поддержка редакторов

.editorconfig поддерживается большинством современных редакторов, но часто требует плагинов.

Visual Studio Code

В VS Code поддержка встроена частично, но рекомендуется расширение EditorConfig.

Поведение:

  • автоматическое применение при открытии файлов
  • соблюдение indent_style и end_of_line
  • конфликт возможен при активированном formatOnSave

JetBrains IDE (WebStorm, PhpStorm)

Поддержка встроена на уровне IDE:

  • автоматическое применение настроек
  • интеграция с кодстайлом проекта
  • приоритет над локальными настройками редактора

Neovim / Vim

Поддержка через плагины:

  • editorconfig-vim
  • интеграция с LSP

Без плагина файл игнорируется.

Использование в монорепозиториях

В монорепозиториях Vite-проекты часто находятся внутри подкаталогов. .editorconfig может быть размещён как в корне, так и в каждом пакете.

Поведение root = true

root = true

Этот параметр останавливает поиск конфигураций выше по дереву директорий.

Стратегии применения

Глобальная конфигурация

Один .editorconfig в корне:

repo/
  .editorconfig
  packages/
  apps/

Подходит для унифицированных проектов.

Локальные переопределения

# packages/app/.editorconfig
root = true

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

Типичные проблемы монорепо

  • разные табуляции между пакетами
  • конфликт LF/CRLF при смешанных ОС
  • несовпадение правил между legacy и новым кодом

Частые ошибки при настройке

Отсутствие root = true

Без этого параметра редакторы могут искать конфигурации выше по дереву, что приводит к неожиданным правилам форматирования.

Несогласованность с Prettier

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

Игнорирование отдельных типов файлов

Отсутствие секций для JSON, YAML или Markdown приводит к визуальной несогласованности проекта.

CRLF в кроссплатформенных командах

Windows-разработчики часто используют CRLF по умолчанию, что приводит к шумным diff в Git и проблемам CI на Linux-агентах.

Практическая структура конфигурации для Vite-проекта с несколькими фреймворками

root = true

[*]
charset = utf-8
indent_style = space
indent_size = 2
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

[*.ts]
indent_size = 2

[*.tsx]
indent_size = 2

[*.vue]
indent_size = 2

[*.css]
indent_size = 2

[*.scss]
indent_size = 2

[*.json]
indent_size = 2

[*.md]
trim_trailing_whitespace = false

Такая структура охватывает типичный стек Vite-проекта с TypeScript, Vue или React, стилями и документацией, обеспечивая единообразие на уровне файлов до этапа сборки и линтинга.

Оглавление