Для предсказуемого форматирования нужны две установки: расширение Prettier в VS Code и пакет Prettier внутри проекта. Расширение связывает форматтер с редактором, а локальная версия позволяет команде и CI применять одинаковые правила.
Просто включить Format on Save недостаточно. VS Code должен знать, какой форматтер использовать для данного языка, а сам форматтер должен найти конфигурацию и суметь разобрать файл. Ниже настроим эту цепочку и отдельно проверим каждый этап.
Установите расширение и локальный пакет
В Extensions найдите Prettier — Code formatter, идентификатор esbenp.prettier-vscode. Проверьте идентификатор, чтобы не поставить похожее расширение с другим поведением.
Откройте корень JavaScript-проекта, где находится package.json, и выполните:
npm install --save-dev --save-exact prettier
npx prettier --version
--save-exact фиксирует установленную версию без диапазона в package.json. Сохраните изменения этого файла и package-lock.json в Git. В существующем проекте с pnpm или Yarn используйте его менеджер, не создавая дополнительный npm lock-файл.
Если Prettier уже установлен, сначала проверьте принятую версию. Не обновляйте её одновременно с исправлением кода: смена форматтера может породить большой посторонний diff. Локальную установку и фиксацию версии рекомендует официальная инструкция Prettier.
Если Node.js и npm ещё не работают, начните с настройки JavaScript. Prettier не требует запуска вашего приложения, но локальному пакету нужен подходящий Node.js.
Создайте .prettierrc.json
В корне проекта создайте .prettierrc.json:
{
"semi": true,
"singleQuote": true,
"tabWidth": 2,
"printWidth": 100,
"trailingComma": "all"
}
Это пример правил, а не обязательный стиль для каждого проекта. Если конфигурация уже есть, соблюдайте её. Не добавляйте рядом второй противоречащий конфиг.
printWidth задаёт ориентир форматирования, а не абсолютную максимальную длину любой строки. singleQuote не заставит JSON использовать одинарные кавычки: синтаксис JSON их не допускает. Параметры объяснены в справочнике опций Prettier.
Настройки команды храните в репозитории. Если задать всё только в личном settings.json, ваш коллега и CI не обязательно получат такой же результат. Поиск конфигурации относительно форматируемого файла описан в Configuration File.
Назначьте Prettier форматтером JavaScript и TypeScript
Добавьте в .vscode/settings.json:
{
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
},
"[javascriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
},
"[typescriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
},
"prettier.requireConfig": true
}
Раздельные языковые блоки позволяют не назначать Prettier для Python или Go. При необходимости добавьте отдельные блоки для HTML и CSS. Не объединяйте все языки в один составной ключ ради сокращения: с editor.defaultFormatter это может работать не так, как ожидается. На этот случай у расширения есть отдельный раздел troubleshooting.
prettier.requireConfig: true означает, что расширение не должно форматировать проект без конфигурации Prettier. Это удобная защита от случайного применения личных правил к чужой кодовой базе. Следствие ожидаемое: забыли .prettierrc.json и форматирования не будет.
Проверьте форматирование вручную, затем сохранением
В учебном .js-файле добавьте:
const user={name:"Mira",active:true};console.log(user)
Сначала вызовите Format Document With..., выберите Prettier, затем Configure Default Formatter..., если редактор ещё спрашивает форматтер. После успешной ручной проверки снова нарушьте отступы и нажмите Ctrl+S либо Cmd+S.
Не связывайте диагностику только с Auto Save: автосохранение и Format on Save являются отдельными механизмами. Для первой проверки нужно явное сохранение. Настройка разных режимов Auto Save есть в общем гайде по VS Code.
Исключите сборки и сторонние файлы
Создайте .prettierignore в корне:
dist/
build/
coverage/
vendor/
Добавьте специфичные для проекта генерируемые файлы. Не исключайте весь исходный каталог, иначе проверка окажется бессмысленной. Prettier использует gitignore-подобные правила; исключения и встроенное поведение описаны в Ignoring Code.
Перед первым запуском на старом проекте ограничьтесь одним исходным файлом. Команда с --write изменяет файлы, поэтому запускать её на всём репозитории лучше отдельным согласованным коммитом.
Добавьте проверку в npm-скрипты
В существующий объект scripts файла package.json добавьте два свойства, сохранив остальные:
{
"scripts": {
"format": "prettier . --write",
"format:check": "prettier . --check"
}
}
Сначала выполните npm run format:check. Проверка не переписывает исходники и сообщает о расхождении оформления. Для исправления используйте npm run format, затем просмотрите diff. В CI обычно нужен вариант --check, а не скрытое изменение файлов. Различия режимов документированы в Prettier CLI.
Если редактор и CLI дают разный результат, сравните версию Prettier, найденный конфиг и фактически выбранный default formatter. Не исправляйте расхождение массовой заменой настроек наугад.
Как использовать Prettier вместе с ESLint
Prettier отвечает за оформление, ESLint может проверять более широкий набор правил кода. Они совместимы, но некоторые стилистические правила ESLint могут спорить с форматтером.
Для устранения таких конфликтов существует eslint-config-prettier, отключающий соответствующие правила. Это не сам форматтер и не средство исправления логических ошибок. Способ подключения зависит от действующего формата ESLint-конфига: не смешивайте старый .eslintrc и flat config по инструкциям разных лет. Рекомендации проекта есть в Integrating with Linters.
Почему Prettier не работает
| Проверка | Что искать |
|---|---|
| Язык файла в строке состояния | Не остался ли Plain Text вместо JavaScript |
| Format Document With | Назначен ли именно Prettier |
| Конфигурация | Есть ли .prettierrc.json, если включён requireConfig |
| Исключения | Не попал ли файл в .prettierignore |
| Output → Prettier | Ошибку синтаксиса, путь конфига, версию форматтера |
| Режим доверия | Разрешено ли расширению использовать компоненты проекта |
| CLI против редактора | Совпадают ли локальная версия и правила |
Успешная настройка выглядит так: один тестовый файл одинаково форматируется вручную, при явном сохранении и через CLI, а повторная проверка не предлагает изменений. После этого можно внедрять правила в остальную кодовую базу.