Подсветка и форматирование в VS Code: разбор на примере

В проекте на TypeScript красный подчёркнутый вызов может быть ошибкой, а разноцветные имена переменных — всего лишь подсветкой. Форматирование отвечает за другое: оно переставляет пробелы, кавычки и переносы строк. На примере VS Code 1.95 и Prettier 3.3.3 настроим эти механизмы отдельно и проверим, почему сохранение иногда неожиданно переписывает файл.

Один файл — три разные задачи

Представьте, что в проекте есть файл src/summary.ts. Редактор распознаёт в нём TypeScript и окрашивает ключевые слова, строки и имена функций. Это подсветка синтаксиса: она помогает читать код, но сама по себе не исправляет ошибки и не переставляет символы.

Отдельно работает проверка типов: встроенная поддержка TypeScript в VS Code может показать, что свойство не существует или аргумент имеет неподходящий тип. И ещё один компонент — форматтер. Он меняет оформление кода по заданным правилам, но не обязан понимать, правильно ли программа считает результат.

Термин: форматтер — инструмент, который автоматически приводит код к заданному стилю оформления. Подсветка, проверка типов и форматирование могут работать в одном редакторе, но это разные функции.

Пусть исходный фрагмент выглядит так:

type Item={name:string;price:number}

export function total(items:Item[]){
return items.reduce((sum,item)=>sum+item.price,0)
}

После форматирования Prettier он станет читабельнее, но логика останется той же:

type Item = { name: string; price: number };

export function total(items: Item[]) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

Подсветка при этом может различаться в зависимости от темы оформления. Это не признак того, что один вариант кода форматирован «правильнее» другого.

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

Какой инструмент поручить оформлению

В VS Code для TypeScript можно оставить встроенный форматтер, поставить Prettier или поручить часть оформления ESLint. Выбор важен: если два инструмента меняют один и тот же файл по-разному, сохранение превращается в спор, а результат зависит от порядка запуска.

В этом разборе форматирует Prettier, а встроенная поддержка TypeScript отвечает за язык и сообщения о типах. ESLint, если он уже есть в проекте, оставляем для правил и диагностики. Это не обязательное разделение: важно заранее решить, какой инструмент отвечает за пробелы, кавычки и переносы строк.

Настраиваем Prettier в проекте

Пример рассчитан на VS Code 1.95, Prettier 3.3.3 и TypeScript. В VS Code установите расширение Prettier — Code formatter от издателя Prettier. Для команды предпочтительна локальная версия пакета: тогда разработчики используют одну и ту же версию форматтера, а не ту, которая случайно обновилась в редакторе.

В корне проекта выполните команду. Она добавит Prettier 3.3.3 как точную версию зависимости разработки:

npm install --save-dev --save-exact prettier@3.3.3

Создайте файл .prettierrc.json в корне проекта. Это полный пример настроек: точка с запятой в конце выражений, одинарные кавычки и запятые в конце многострочных списков.

{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all"
}

Чтобы настройки относились к проекту, а не только к вашему профилю редактора, создайте .vscode/settings.json:

{
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": true
  }
}

Так мы выбираем форматтер для файлов TypeScript и включаем форматирование при сохранении. Если в проекте есть TypeScript JSX, добавьте отдельный блок для языка typescriptreact; не включайте настройку глобально, если другие файлы должны форматироваться иначе.

Проверяем, кто меняет файл

1. Откройте src/summary.ts и посмотрите на цвета кода. Если редактор распознал TypeScript, ключевые слова и строки отображаются по-разному. Это проверка подсветки, она не требует сохранения файла.

2. Внесите в файл неровные отступы из примера выше и сохраните его. При включённом editor.formatOnSave Prettier должен привести фрагмент к выбранному стилю. Проверка: отступы и точки с запятой изменились, а выражение для суммы осталось тем же.

3. Запустите форматтер вручную через палитру команд VS Code: откройте команду Format Document. Если редактор спросит, какой форматтер использовать, выберите Prettier. Проверка: после повторного запуска файл уже не меняется.

4. Проверьте файл через локальную зависимость командой:

   npx prettier src/summary.ts --check

   Проверка: если стиль совпадает, Prettier сообщает, что файл соответствует форматированию; если нет — указывает файл как требующий форматирования.

Не путайте результат Prettier с проверкой TypeScript. Файл может быть аккуратно оформлен и при этом содержать ошибку типов. И наоборот: редактор может не показывать ошибок, хотя отступы не совпадают со стилем проекта.

Что ломается и почему

Сохранение меняет стиль не так, как ожидали

Частая причина — проектные настройки не загружены или активен другой форматтер. Откройте настройки для конкретного языка и проверьте editor.defaultFormatter. Затем в палитре команд выберите Format Document With и посмотрите, какой инструмент VS Code предлагает для текущего файла.

Команда проверки ругается на файл

prettier --check проверяет, соответствует ли файл правилам, но не исправляет его. Для применения форматирования используйте локальный вызов npx prettier src/summary.ts --write, затем проверьте diff в системе контроля версий. Если после форматирования появилось много изменений, сначала выясните, не применился ли другой конфиг или версия.

ESLint и Prettier переписывают одни и те же строки

Если оба инструмента задают правила кавычек, точек с запятой или переносов, их требования могут разойтись. Тогда ESLint исправит файл в одну сторону, а Prettier — в другую. Проверьте конфигурации обоих инструментов и закрепите единый источник правил оформления; не добавляйте новые расширения только ради устранения симптома.

Цвета отличаются у коллег

На цвета влияют тема редактора и настройки подсветки. Это не форматирование, поэтому изменение палитры не должно менять содержимое файла. Если важно, чтобы команда одинаково видела подсветку, договоритесь о теме отдельно — она не заменяет конфигурацию форматтера.

Когда выбирать каждый вариант

Оставьте встроенный форматтер, если проект небольшой, дополнительных инструментов нет и текущего оформления достаточно. Выбирайте Prettier, если команде нужно единообразно форматировать код и вы готовы закрепить его версию и настройки в репозитории. Используйте ESLint для проверок и автоматических исправлений, но заранее определите, какие именно правила оформления остаются за ним.

Если проект уже настроен, не меняйте форматтер посреди задачи без обсуждения: один массовый коммит с переоформлением может усложнить просмотр изменений. Сначала проверьте настройку на отдельном файле и сравните diff. Интеграция Prettier с ESLint — отдельная тема; здесь мы разбирали выбор форматтера и его работу в VS Code.

Что проверить дальше

Зафиксируйте в репозитории конфиг Prettier, точную версию пакета и проектные настройки VS Code. Затем проверьте на одном файле три результата отдельно: подсветку, форматирование при сохранении и диагностику TypeScript. После этого посмотрите на изменения в diff и запустите проверку форматирования для файла или проекта. В рабочей команде следующий шаг — добавить такую проверку в общий процесс перед слиянием изменений, чтобы стиль не зависел от настроек одного разработчика.