VS Code Code Actions on Save

Как устроен editor.codeActionsOnSave

Code Action — это не один встроенный «автофикс», а общий механизм, куда языковые сервисы и расширения добавляют доступные действия. Поэтому список возможных source actions зависит от открытого проекта и активных расширений. В JavaScript/TypeScript часто встречаются source.organizeImports и source.fixAll; ESLint может предоставлять свой fixAll.eslint. VS Code показывает подсказки для editor.codeActionsOnSave на основе текущего workspace. Важный нюанс: наличие настройки не гарантирует, что конкретное действие существует для любого файла. Если провайдер не зарегистрировал соответствующий Code Action, сохранять файл можно сколько угодно — изменений не будет. Сначала убедитесь, что ручной Quick Fix или Organize Imports вообще доступен в этом языке.

Совет: Если действие не срабатывает, проверьте его вручную через Command Palette или Ctrl+. — так быстрее понять, проблема в провайдере или в событии сохранения.

Базовая настройка в settings.json

1. Откройте Settings JSON командой Preferences: Open User Settings (JSON) либо Workspace Settings (JSON), если правило должно действовать только в проекте.
2. Добавьте объект: "editor.codeActionsOnSave": { "source.organizeImports": "explicit" }.
3. Сохраните настройки и откройте файл языка, где поддерживается Organize Imports. Внесите неиспользуемый или неправильно упорядоченный импорт и нажмите Ctrl+S.
4. Если действие должно запускаться и при Auto Save, замените значение на "always". Если его нужно явно запретить, используйте "never".
5. Для нескольких действий добавьте отдельные ключи. Учитывайте, что действия могут менять один и тот же участок кода и иногда конфликтовать.
6. Если порядок критичен, задайте действия в том порядке, в котором хотите их запускать: VS Code выполняет перечисленные Code Actions последовательно. После настройки сделайте тестовый save и проверьте diff.

Важно: Булевы true/false ещё могут встречаться в старых примерах, но документация VS Code рекомендует современные значения explicit, always и never.

explicit, always и never — в чём разница

Значение explicit означает запуск при явном сохранении, то есть когда пользователь действительно вызывает команду Save. Это хороший безопасный вариант для действий, которые заметно переписывают импорт или код. always расширяет поведение на Auto Save в поддерживаемых сценариях, включая сохранение при потере фокуса или окна. В большом проекте это может означать значительно больше автоматических правок, чем ожидает разработчик. never полезен для явного отключения action в конкретном scope, особенно если пользовательская настройка включила его глобально, а workspace хочет запретить. Выбор зависит от дисциплины проекта: для командной разработки часто разумно сначала сделать автоматизацию предсказуемой на Ctrl+S, а затем уже включать её на каждый Auto Save.

Как ограничить автодействия одним языком

Если JavaScript должен организовывать импорты на сохранении, а JSON, Python или другой язык — нет, используйте language-specific settings. В settings.json можно создать секцию [javascript] или [typescript] и поместить editor.codeActionsOnSave внутрь неё. Это особенно полезно, когда разные стеки используют разные линтеры и форматтеры. Не путайте Code Actions с editor.formatOnSave: форматтер отвечает за форматирование, а source actions могут менять структуру импортов, применять quick fixes и делать иные семантические правки. Оба механизма могут работать вместе, но при проблемах лучше временно отключить один и проверить второй отдельно. Так проще диагностировать, откуда взялось неожиданное изменение файла.

Почему настройка может давать разный результат в двух проектах

Одинаковый settings.json не гарантирует одинаковые правки в двух репозиториях. Code Actions предоставляются языковыми сервисами и расширениями, а их набор зависит от установленных версий ESLint, TypeScript, Python-инструментов и конфигурации самого проекта. В одном workspace source.fixAll может исправить десяток диагностик, в другом — не сделать ничего. Кроме того, Remote SSH, Dev Containers и WSL имеют собственный контекст расширений и settings scope. Если настройка работает локально, но не в контейнере, проверьте, установлено ли нужное расширение именно в удалённой среде и не переопределён ли editor.codeActionsOnSave в Remote или Workspace Settings.

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

Когда на сохранении работают сразу organizeImports и fixAll, не проверяйте настройку на десятках файлов. Создайте один небольшой файл с двумя контролируемыми проблемами: например, лишним импортом и исправляемой диагностикой линтера. Сначала включите только первое действие и сохраните файл, затем добавьте второе. VS Code выполняет Code Actions в указанном порядке, поэтому diff должен показать, какое действие сработало первым и не отменило ли второе его результат. Если расширение ESLint или другой провайдер меняет тот же участок кода, возможны повторные правки или отсутствие ожидаемого эффекта. В таком случае лучше сузить глобальный source.fixAll до конкретного провайдера, например source.fixAll.eslint, если именно его исправления нужны проекту. Для командного репозитория закрепите настройку в workspace только после такого теста. Это снижает риск ситуации, когда у одного разработчика сохранение меняет десятки строк, а у другого — ничего, потому что набор расширений и их конфигурация различаются.

Если Code Actions on Save не работает

• Проверить, доступно ли действие вручную для текущего языка.
• Убедиться, что settings.json валиден и нет дублирующей настройки ниже.
• Проверить User, Remote и Workspace scopes: более специфичная настройка может переопределять общую.
• Убедиться, что нужное расширение включено и доверено workspace.
• Разделить formatOnSave и codeActionsOnSave при диагностике.
• Посмотреть Output/Problems конкретного расширения, если автофикс завершается ошибкой.

Совет: Для командного проекта храните workspace-настройки рядом с конфигурацией линтера и форматтера. Тогда поведение сохранения легче воспроизвести у всех участников.

Что учитывать

Если JavaScript должен организовывать импорты на сохранении, а JSON, Python или другой язык — нет, используйте language-specific settings. В settings.json можно создать секцию [javascript] или [typescript] и поместить editor.codeActionsOnSave внутрь неё. Это особенно полезно, когда разные стеки используют разные линтеры и форматтеры. Не путайте Code Actions с editor.formatOnSave: форматтер отвечает за форматирование, а source actions могут менять структуру импортов, применять quick fixes и…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Refactoring in Visual Studio Code). Пример и формулировки — редакция N1RO на 2026-09-20.

• Refactoring in Visual Studio Code