Конструктор запросов 1С прямо в VS Code — без Конфигуратора и EDT

Зачем это нужно

Конструктор запросов — один из самых удобных инструментов платформы 1С. Но чтобы им воспользоваться, обычно нужно запустить Конфигуратор или EDT и открыть конкретную информационную базу. Если вы пишете и читаете код 1С в VS Code (а таких разработчиков всё больше — с git, выгрузкой конфигурации в файлы, code review по диффам), переключение на тяжёлую платформу ради одного запроса занимает слишком много времени. Расширение query_console_vscode закрывает этот разрыв. На основе этой выгрузки расширение парсит метаданные, строит дерево «таблицы → поля → типы → связи» и даёт собрать запрос мышью — ровно как привычный конструктор платформы. Результат — текст на языке запросов 1С (SDBL), вставленный в код в правильном формате (строковый литерал с переносами |).

Возможности

• Парсинг метаданных конфигурации из выгрузки в файлы.

• Визуальное построение запросов с учётом возможностей языка запросов 1С: таблицы и поля, условия, группировки, объединения и псевдонимы, порядок, ИТОГИ, пакеты запросов.

• Открытие сохранённого текста запроса из кода с проверкой синтаксиса и наличия таблиц — можно взять готовый запрос из .bsl, поправить мышью и вернуть обратно.

• Сохранение комментариев внутри текста запроса при цикле «открыть → править → сохранить».

Как пользоваться

Для файлов .bsl команда «1С: Конструктор запроса» добавлена в контекстное меню (правая кнопка):

• если курсор стоит внутри текста сохранённого запроса — команда открывает этот запрос в конструкторе;

• если курсор в другом месте — расширение предложит создать новый запрос.

По нажатию ОК: для открытого запроса текст заменяется на собранный конструктором, для нового — вставляется в позицию курсора.

Конструктор работает не с выгрузкой напрямую, а с кэшем разобранных метаданных. При первом открытии, если кэша ещё нет, выполняется парсинг (путь к выгрузке — из настройки queryConsole.metadataPath; если пусто, ищется src/cf в корне рабочей области). После изменения метаданных конфигурации нажмите «Обновить кэш» — выгрузка перепарсится, дерево перестроится.

Настройки:

• queryConsole.metadataPath — путь к каталогу выгрузки cf (пусто → автоопределение);

• queryConsole.parserOutputPath — каталог результата парсинга (по умолчанию tmp/parser_data).

Кому это пригодится

1. Тем, кто работает в VS Code без Конфигуратора и EDT. Если основная среда разработки — VS Code (с git, линтерами, своими расширениями), конструктор запросов теперь доступен прямо в ней. Не нужно запускать платформу и подключать базу только чтобы собрать или поправить запрос.

2. Тем, кто ведёт много проектов сразу. Когда на машине десяток конфигураций, держать под каждую открытый Конфигуратор накладно. Здесь же конструктор работает с выгрузкой в файлы: переключение между проектами — это переключение между папками/рабочими областями VS Code. Никаких «поднять базу, открыть конфигуратор, дождаться загрузки конфигурации».

3. Тем, кто хочет дописать недостающие фичи конструктора через вайбкодинг. Проект открытый и собран так, что его легко расширять с помощью ИИ-ассистента. Не хватает какой-то конструкции языка запросов или удобной кнопки в UI — её реально добавить «вайбкодингом»: ядро отделено от UI, есть тесты и замкнутый цикл проверки корректности (см. ниже), так что новая фича сразу проверяется на регрессе.

4. Тем, кто строит более сложные инструменты поверх метаданных и запросов. Под капотом — два переиспользуемых движка: парсер метаданных (выгрузка cf → структурированная модель «таблицы → поля → типы» в YAML) и парсер/генератор запросов 1С (текст SDBL ↔ объектная модель запроса). На этой основе можно делать гораздо больше, чем просто конструктор: статический анализ запросов, массовый рефакторинг, проверку запросов на соответствие метаданным, документирование схемы данных, миграции, линтеры и т. п.

Подробно про сохранение комментариев

Это та фича, которой обычно не хватает: штатный конструктор платформы при открытии-сохранении запроса теряет комментарии. Здесь комментарии переживают цикл «открыть → править → сохранить».

В шапке конструктора есть галочка «Сохранять комментарии» (включена по умолчанию). Если её снять — комментарии при вставке убираются.

Ключевая идея: комментарии привязываются к смысловым элементам запроса (полю, контейнеру пакета), а не к позиции в тексте. Поэтому они переживают перестановку полей и удаляются вместе со своим полем/таблицей — ведут себя так, как ожидает разработчик.

Сохраняются 4 вида комментариев:

1. Хвост строки после поля — Поле КАК Син, // комментарий;

2. Отдельной строкой перед полем;

3. Отдельной строкой перед ВЫБРАТЬ;

4. Отдельной строкой после ИЗ.

Пример. Был запрос:

ВЫБРАТЬ
    // основной идентификатор
    Номенклатура.Ссылка КАК Ссылка,
    Номенклатура.Наименование КАК Имя, // витринное имя
    Номенклатура.Артикул КАК Артикул
ИЗ
    // только активные позиции
    Справочник.Номенклатура КАК Номенклатура

Открываем его в конструкторе, мышью меняем порядок полей (например, ставим «Артикул» вторым) и сохраняем. Комментарий // основной идентификатор останется перед полем «Ссылка», хвостовой // витринное имя уедет вместе с полем «Имя» на новую позицию, комментарий после ИЗ про «только активные позиции» сохранится. Если поле «Имя» удалить — вместе с ним исчезнет и его хвостовой комментарий: висячих, потерявших смысл комментариев не остаётся.

Ограничения (важно понимать заранее):

• только однострочные комментарии //…;

• сохраняются только 4 перечисленные позиции — остальные отбрасываются (например, хвостовые комментарии на строках ключевых слов: ВЫБРАТЬ //…, ИЗ //…);

• комментарий удаляется при удалении или переименовании его «якоря»: поля (удаление, смена синонима/выражения) или контейнера (переименование/смена типа временной таблицы);

• при снятой галочке «Сохранять комментарии» все комментарии теряются при вставке.

Как сделан проект

Вайбкодинг с Claude по TDD + SDD. Проект написан в связке с ИИ-ассистентом Claude, но не «как получится», а по двум дисциплинам сразу:

• SDD (Spec-Driven Development) — каждой итерации предшествует дизайн-документ (спека) и план реализации; они лежат в репозитории (docs/superpowers/specs/, docs/superpowers/plans/). Сначала проектируем, потом кодируем.

• TDD (Test-Driven Development) — сначала тест, потом код. Ядро (src/core) — чистый TypeScript без зависимостей от vscode/React, поэтому полностью тестируется в Node. Генератор SDBL дополнительно проверяется тест-оракулом: сгенерированный текст парсится через tree-sitter-sdbl (WASM) и должен разбираться без ошибок.

Архитектура специально сделана «расширяемой ИИ»: логика изолирована в core, UI — «тонкий» React-webview, контракт между слоями сосредоточен в одном файле сообщений. Такую структуру легко наращивать вайбкодингом — новая фича не размазывается по всему коду.

Замкнутый цикл проверки корректности — главная гарантия качества. Чтобы генерируемые запросы действительно были правильными, а не «похожими на правду», построен замкнутый цикл проверки на реальном MCP-оракуле 1С:

• В качестве эталона используется MCP-сервер 1c_mcp Владимира Харина — с небольшой доработкой: он возвращает нормализованный текст запроса, полученный через объект СхемаЗапроса платформы. То есть эталоном выступает не самописный форматтер, а сама платформа 1С: как СхемаЗапроса собрала текст обратно — так и должно быть.

• Конвейер корпусного тестирования (npm run corpus:test): из конфигурации извлекаются реальные запросы (из строковых литералов .bsl и из макетов СКД в Reports/**/*.xml), плюс автоматически формируются эталонные ВЫБРАТЬ * ИЗ <Тип>.<Объект> ко всем таблицам метаданных. Все они валидируются через MCP-оракул, и валидные с их нормализованным текстом складываются в «золотой» эталон (golden.jsonl).

• Затем каждый запрос прогоняется через наш конструктор (текст → модель → снова текст), и вывод сравнивается с эталоном оракула. На каждое расхождение пишется отдельный самодостаточный JSON-файл: исходный текст, эталон платформы, вывод конструктора, класс ошибки и номер расходящейся строки. По этим файлам заводятся точечные правки — без необходимости заново гонять весь конвейер.

Проверка на БСП и УНФ. Корпус прогонялся на запросах из реальных типовых конфигураций — Библиотеки стандартных подсистем (БСП) и Управления нашей фирмой (УНФ). Это тысячи живых запросов со всем разнообразием конструкций языка. Закоммиченный регресс-эталон (1976 запросов, 0 расхождений) включён в обычный прогон npm run test:unit и воспроизводится на любом checkout'е без подключения к базе — то есть корректность зашита в CI.

Тестирование UI через Playwright. Webview-конструктор покрыт end-to-end тестами на Playwright: реальные клики по дереву и панелям, проверка генерируемого текста и поведения вкладок. Так UI-регрессии ловятся автоматически, что важно, когда новые фичи добавляются вайбкодингом.

Итого получается честный замкнутый контур: спека → тест → код → прогон на реальных запросах БСП/УНФ → сверка с платформой через СхемаЗапроса → точечная правка по файлам ошибок → регресс-gate в CI. Именно это позволяет доверять выводу конструктора и спокойно расширять его с ИИ.

Установка (VSIX)

Готовый .vsix собирается автоматически в GitHub Actions по git-тегу и прикладывается к GitHub Release.

1. Скачайте query-console-1c-<тег>.vsix со страницы Releases.

2. Установите одним из способов:

Через UI VS Code: панель Extensions (Ctrl+Shift+X) → меню «...» → Install from VSIX... → выбрать файл.

Через командную строку (--force — для обновления поверх установленной версии):

code --install-extension query-console-1c-<тег>.vsix

code --install-extension query-console-1c-<тег>.vsix --force

Скачать и установить одной командой:

curl -L -o qc.vsix \

  https://github.com/AlekseyUAM/query_console_vscode/releases/latest/download/query-console-1c-<тег>.vsix

code --install-extension qc.vsix

Для VS Code Insiders используйте code-insiders, для VSCodium — codium. После установки при необходимости перезагрузите окно (Ctrl+Shift+P → Reload Window).

Собрать из исходников: нужен Node.js ≥ 20 (рекомендуется 22), затем npm install и npm run package. Подробности — в docs/DEVELOPMENT.md.

Ссылки

• Репозиторий проекта: https://github.com/AlekseyUAM/query_console_vscode

• MCP-расширение 1С (основа цикла проверки): https://github.com/vladimir-kharin/1c_mcp