XBSL для VS Code

Расширение VS Code для 1С:Элемент: подсветка синтаксиса, линтинг на лету с Quick Fix, визуальный конструктор форм, обозреватель метаданных и навигация по проекту – всё на движке xbsl.

Подсветка синтаксиса и проверка исходников 1С:Элемент (.xbsl) на лету движком xbsl. Вместе с ней – конструктор форм, дерево метаданных, панель документации платформы, создание метаданных, отладка и кнопка деплоя.

Хотите посмотреть всё сразу на небольшом проекте? Откройте папку demo/ репозитория. Это крошечное приложение 1С:Элемент с формой и несколькими намеренными находками линтера.

Проверка буфера YAML ограничена настроенным корнем проекта и его словарём перевода. Быстрые исправления доступны для YAML и модулей. Сохранение отменяет ожидающие ответы по буферу: запоздавший результат не заменит новый отчёт проекта и его исправления.

Каркас формы показывает ОбычныеКоманды в подвале и признаки Наклонный, Подчеркивание, Зачеркивание абсолютного шрифта. Подсказки используют написания свойств исходной формы.

Расширение использует движок xbsl 1.0.0. Установите его в Python, выбранный настройкой xbsl.linter.pythonPath.

Значок обновления в строке состояния заново строит индекс и проверяет все исходники проекта. Во время проверки рядом с вращающимся значком видны этап и его процент, например 4/8 Файлы · 43%. Подсказка показывает выполненные и оставшиеся файлы или правила, текущее правило проекта и прошедшее время, обновляемое раз в секунду. У каждого этапа свой процент. После публикации диагностик и завершения проверки кнопка снова показывает только значок обновления.

Как это устроено

Расширение – тонкий клиент движка xbsl. В режиме LSP, который включён по умолчанию, к одному долгоживущему серверу xbsl-lsp обращается всё: диагностика, навигация, панель документации и создание метаданных. Без сервера те же проверки и создание метаданных идут через CLI:

В режиме CLI одну коллекцию диагностик наполняют два источника. Расширение выбирает источник по состоянию буфера.

• Пока вы печатаете. У несохранённого буфера модуля, YAML проекта или файла словаря перевода расширение запускает xbsl --stdin --filename <имя> --format json по тексту, который сейчас в редакторе. Работают только пофайловые правила, поэтому ответ приходит быстро; сам запуск отложен на задержку. Результат замещает диагностики только этого буфера.
• По сохранению. Сохранение любого .xbsl или .yaml запускает в фоне xbsl <корень проекта> --format json. Если словарь перевода лежит вне корня, рядом запускается xbsl <словарь>, и проектные правила словаря не видят. Запуск тоже отложен, и одновременно идёт не больше одной проверки: сохранение посреди проверки отменяет устаревшую и начинает заново. Результат покрывает и пофайловые, и проектные правила, поэтому замещает диагностики всех файлов, которые проверка прочитала. Буферы, к тому моменту снова несохранённые, до следующего сохранения остаются с картиной от --stdin. Модули, открытые вне корня проекта, тоже сохраняют свою картину: проверка их не читает.

Так не появляется ни дублей, ни потерянных правил. У сохранённого файла видна полная картина проверки по всей папке, у редактируемого – мгновенная пофайловая, и каждое сохранение сводит их вместе. Обе проверки отдают один JSON-контракт {diagnostics, summary} – тот же, что и MCP-сервер линтера.

Фоновая проверка, которая упала или превысила xbsl.workspaceLintTimeout, попадает только в панель вывода XBSL. Всплывающих окон на каждое сохранение нет.

Возможности

• Подсветка синтаксиса .xbsl: ключевые слова (русские и английские формы), объявления, операторы, @-декораторы, числа, комментарии и строки с интерполяцией %имя / ${...}.
• Живые диагностики при наборе (с задержкой) и по сохранению. Сюда попадает всё, что видит линтер: баланс скобок и блоков, неиспользуемые переменные, типографика, соглашения по стилю. У подчёркивания есть идентификатор правила (например, code/brackets) и важность.
• Диагностики по всему проекту. Сохранение любого .xbsl/.yaml запускает линтер по всей рабочей папке в фоне, поэтому проектные правила (code/unknown-type, yaml/unknown-type, уникальность Ид) видны в редакторе сразу по всем файлам. Управляется настройкой xbsl.workspaceLint (включено по умолчанию).
• Проверка всего проекта по требованию – команда XBSL: проверить весь проект.
• Переход к определению, поиск всех ссылок и автодополнение по проекту. Отвечает языковой сервер по своему индексу проекта. См. Навигация и автодополнение.
• Quick Fix для механических находок. Лампочка на исправимой диагностике (хвостовые пробелы, типографские символы) применяет ровно ту правку, которую сообщил линтер. Действие исправить все (source.fixAll.xbsl) чинит весь файл и умеет запускаться по сохранению через editor.codeActionsOnSave. См. Quick Fix.
• Деплой на стенд. Команда XBSL: деплой на стенд (elemctl) и кнопка-облачко в заголовке дерева метаданных запускают elemctl deploy терминальной задачей: сборка из исходников → загрузка → применение → перезапуск → проверка того, что сборка действительно применилась. См. Деплой на стенд.
• Конструктор формы – панель из трёх областей: дерево структуры слева, данные формы справа, каркас формы под ними. Панель следует за активным редактором и обновляется при наборе. Выделение связано между областями, курсором в yaml и панелью свойств. Палитра компонентов стоит рядом с деревом метаданных, пока панель открыта. См. Конструктор формы.
• Обозреватель метаданных – дерево объектов проекта в основной боковой панели, по видам, с поддеревьями (реквизиты, измерения, формы, значения перечисления …). Есть редактируемая панель свойств, создание объектов, полей и подсистем, отбор по подсистемам и пакетам. См. Обозреватель метаданных.
• Документация – вид во вторичной боковой панели: справка 1С:Элемент как на сайте. Дерево “Содержание” (руководства разработчика и администратора, справочники типов, свойств и языка запросов), полнотекстовый поиск, просмотр страницы с картинками и ссылкой на первоисточник. Правый клик на типе или переменной открывает её документацию. См. Документация.

Раскладка панелей. Расширение объявляет два контейнера, и раскладка со снимка выше получается сама. 1С:Элемент • Проект (дерево метаданных и палитра) встаёт в основную боковую панель слева, 1С:Элемент • Инспектор (свойства и документация) – во вторичную справа, рядом с чатом. Раскладка не закреплена: значок контейнера перетаскивается между панелями, а команда Вид: сбросить расположение представлений возвращает умолчание. Вторичная панель показывается и скрывается по Ctrl+Alt+B (Вид > Внешний вид > Дополнительная боковая панель).

.yaml-описания элементов сохраняют встроенную подсветку YAML.

Требования

Расширение – тонкий клиент над CLI xbsl, проверку оно не встраивает. Нужны:

1. Python 3.10+ и линтер: pip install xbsl. Если линтер не найден, расширение предложит установку прямо из сообщения об ошибке.
2. Данные языка Элемента. Они генерируются один раз из вашего дистрибутива 1С:Элемент, см. шаг 1 README линтера. Без них большинство правил не работает; ошибку линтера расширение показывает один раз.

По умолчанию расширение зовёт xbsl из PATH. Перенаправить можно настройками xbsl.linter.command (исполняемый файл) или xbsl.linter.pythonPath (интерпретатор – линтер тогда запускается как <python> -m xbsl).

Движок и расширение ставятся по отдельности. При обновлении расширения обновляйте и движок командой pip install -U xbsl.

Новый проект

Команда XBSL: новый проект 1С:Элемент (xbsl.project.new) заводит проект с нуля. Мастер спрашивает четыре вещи: имя проекта, поставщика, вид проекта (приложение или библиотека) и папку. Дальше он создаёт заготовку через тот же движок, что и остальные операции с метаданными, и открывает готовый Проект.yaml.

Поставщик запоминается между запусками: у одного разработчика он обычно один и тот же. Если проект создан вне открытой папки, расширение предложит открыть его – свежий проект редко оказывается частью текущего окна.

Структурный поиск по формам

Команда XBSL: структурный поиск по формам (xbsl.forms.search) ищет не по тексту, а по структуре. Задаётся тип компонента и, если нужно, условия по свойствам вида ключ=значение. Расширение собирает формы проекта вместе с несохранёнными буферами, отдаёт их движку и показывает совпадения списком. Выбор перемещает курсор на строку компонента в его yaml.

Поиск нужен, когда вопрос звучит как “где у нас поля ввода с таким-то свойством”. Текстовым поиском такое не находится: в yaml свойство и тип компонента лежат на разных строках.

Требует режима LSP: подбор совпадений выполняет движок, а в режиме CLI он не запущен.

Навигация и автодополнение

Навигацию даёт движок. Индекс проекта держит языковой сервер, он же отвечает на переход к определению, поиск ссылок, автодополнение и подсказки. Второй реализации у расширения нет, поэтому навигация знает ровно то же, что движок: типы возврата проектных методов, члены платформенных типов. Без режима LSP навигации нет – в режиме CLI спрашивать некого.

Переход к определению (F12 / Ctrl+клик), в .xbsl и .yaml:

• имя объекта проекта (голое или корень точечной цепочки) → его .yaml;
• Объект.ЛокальныйТип → объявление типа; Объект.ТабличнаяЧасть → секция в yaml объекта; Перечисление.Значение → строка значения;
• Модуль.Метод (включая модули менеджера, названные по объекту) и голое имя метода внутри своего модуля → метод;
• Компоненты.Имя → узел компонента в yaml текущей формы; Компоненты.Имя.Метод → метод модуля этой формы;
• в yaml значение Обработчик: Имя → обработчик в парном .xbsl.

Найти все ссылки (Shift+F12 или Перейти к ссылкам / Найти все ссылки в контекстном меню), для методов, объектов и компонентов интерфейса – все использования по тому же индексу:

• метод → его вызовы внутри модуля, Модуль.Метод и Компоненты.Модуль.Метод, а также обработчики Обработчик: Имя в yaml;
• объект → все места, где он корень точечной цепочки;
• компонент → его обращения Компоненты.Имя в модуле формы.

Поиск ссылок идёт по индексу имён, а не по типам, поэтому цепочку он не разбирает. Переход к определению устроен так же.

Автодополнение (по . и :, а в строке /// – по @ и /):

• после Объект. – семейство типов (Ссылка, Объект, …), табличные части, локальные типы и методы модуля менеджера; для перечисления – его значения;
• после Компоненты. – компоненты текущей формы; после Компоненты.X. – методы модуля X;
• в yaml после Тип: – имена объектов проекта (вид объекта показан в подсказке).

Дополнение по типам работает только в режиме LSP. Разбор идёт по токенам, поэтому ключевые слова понимаются в обеих формах – пер/var, новый/new:

• внутри Запрос{ ... } после таблицы – её поля: стандартные поля вида, реквизиты и табличные части. Таблица узнаётся и по алиасу: ИЗ Акция КАК А → после А. те же поля;
• после переменной цикла по результату запроса (для С из Результат → С.) – колонки выборки (алиасы ВЫБРАТЬ ... КАК; у поля без алиаса именем становится последний сегмент);
• после переменной известного типа (пер Список = новый Массив<Строка>() → Список.) – члены этого типа. Тип берётся из аннотации, из новый, из литерала (знч Ключ = "" – это Строка) или из вызова: и через модуль (Модуль.Метод()), и без квалификатора – вызов метода того же модуля. Годятся и параметры метода;
• после значения проектного типа – его поля и методы: структура модуля, тип, описанный в метаданных, компонент интерфейса (у формы – её Свойства, методы её модуля и члены платформенного типа из Наследует);
• внутри новый Тип( – имена того, что тип несёт: подстановка сразу пишет Имя = ;
• после типа или глобали stdlib (КонтекстДоступа.) – её члены. Свойства и методы показаны раздельно: у метода свой значок, и вставляется он со скобками.

Цепочка проходится до конца, а не на один уровень: Разбор.Файл!.Прочитать(). отвечает членами результата, настойчивая операция цепочку не обрывает. Переменная цикла берёт элемент из записанного типа коллекции (Массив<Каталог.Карточка> → Каталог.Карточка), в том числе когда коллекция пришла из вызова.

Члены типов stdlib берутся из данных Элемента (каталог --data-dir), остальное – из индекса проекта. Имя в области видимости сильнее одноимённого типа: если объявлена переменная Список, то Список. – это про её тип, а не про компонент Список.

Документирующие комментарии. Метод, описанный строками ///, читается в редакторе так же, как в среде разработки:

• подсказка при наведении на метод проекта показывает описание и раздел для каждого вида тегов – “Параметры”, “Возвращает”, “Выбрасывает”, “Смотреть также”; параметры и исключения идут списком Имя - текст;
• справка по сигнатуре при вызове метода проекта (по ( и ,) показывает сигнатуру, а для аргумента, который сейчас пишется, – текст его тега @параметр;
• в строке /// по @ предлагаются теги на языке модуля; после @параметр – параметры метода ниже, которые блок еще не описал; в единственной строке блока или в пустой строке прямо над объявлением – блок, который пишет шаблон самой среды: описание, строка на каждый параметр, результат;
• слово тега и имя после него подсвечиваются так, как подсвечивается тег JSDoc.

Правила comment/doc-tag-* сверяют теги с сигнатурой и с тем, что покажет среда разработки.

Известные пределы. Вне режима LSP индекс знает объявления, а не типы, поэтому дополнения после переменных нет. Тип не выводится там, где его неоткуда взять: у обобщённого метода платформы, где результат задаётся аргументом-типом; у выражения с операциями ("а" + Х – это операция, а не литерал); у имени, которого нет в каталоге платформы. Члены платформенных типов подсказываются русскими написаниями и в проекте на английском, потому что английской пары в каталоге у них нет. Переименования нет. В неоднозначном контексте подсказка не появляется вовсе.

Quick Fix

Находки, которые линтер чинит механически, несут правку, и расширение превращает её в Quick Fix:

• Лампочка на диагностике (Ctrl+.) – Исправить: <правило> – применяет точную правку: снятые хвостовые пробелы, длинное тире → среднее, … → ..., кудрявые кавычки → прямые.

• Действие “исправить все” – Исправить все (xbsl) – чинит все исправимые находки файла одной правкой. Чтобы запускать его по сохранению, добавьте в настройки:

  "editor.codeActionsOnSave": { "source.fixAll.xbsl": "explicit" }

Движок передаёт правки в JSON. Предлагаются только однозначные правки и только к тому тексту, на котором они были вычислены: снимок с версией защищает от применения смещения к изменившемуся тексту. Правки всего файла (смешанные переводы строк) остаются за xbsl --fix в командной строке.

У находки, чинить которую надо в другом файле, своя лампочка. Правило conventions/missing-translation предлагает записать слово в словарь проекта – см. Словарь перевода.

Настройки

В режиме LSP yaml-файлы выбираются относительно вычисленного корня проекта. Относительный корень разрешается от первой папки рабочей области. На Windows регистр пути корня не учитывается, на Linux используется чувствительное к регистру сопоставление VS Code.

Правила: уровни и отключение

Старые настройки (xbsl.groups.*, linter.select / .enable / .ignore) код читает по-прежнему, но в формах их больше нет. Перенести их в таблицу разом – команда XBSL: перенести настройки правил в одну таблицу.

Таблицу не обязательно править руками. Команда XBSL: правила открывает панель: все правила движка списком по группам, у каждого свой уровень или “по умолчанию”, поиск по имени, фильтр “только изменённые” и кнопка сброса. Область записи выбирается явно – настройки пользователя или рабочей области. Пишет панель ровно в xbsl.rules, второй модели настроек нет.

По группам – в UI настроек. Секция “Группы правил” (наберите xbsl.groups в поиске настроек или пройдите Расширения → XBSL) даёт выпадающий список на каждый тип находок: код, описания yaml, стиль, типографика, пробелы, кодировка, структура, формы, запросы, именование, проект, безопасность. Из списка выбирают одно из трёх: оставить собственные уровни правил группы, показывать все её находки одним уровнем (error / warning / info / hint) либо выключить группу целиком. Значение off не просто прячет находки, а исключает правила из проверки.

По отдельным правилам – с находки. У каждой находки в лампочке (Ctrl+.) есть действие “Настроить правило…”: отключить правило или переопределить его уровень, не уходя со строки. Проверка тут же перезапускается. Выбор сохраняется в настройку xbsl.rules – словарь из идентификатора правила (whitespace/trailing) или целой группы (style) в уровень или off. Точный идентификатор сильнее группы, а любой ключ xbsl.rules сильнее выпадающих списков групп. Работает и в режиме CLI, и в режиме LSP.

У группы правил, добавленной надстройкой движка, своего выпадающего списка нет – списки перечисляют встроенные группы движка. Такая группа настраивается через xbsl.rules по своему имени ({"conventions": "off"}) либо действием “Настроить правило…” на любой её находке. Оба пути работают с группой надстройки точно так же, как со встроенной.

Исключение находки (список принятых)

Отключение правила глушит его везде. Иногда же исправлять нужно не всё: одна находка законна, код правильный намеренно. Для этого у каждой находки в лампочке (Ctrl+.) есть действие “Исключить эту находку (в список принятых): <правило>”. Введите причину, и находка вместе с причиной попадёт в файл принятых замечаний – по её приметам, то есть по файлу, правилу и тексту сообщения. Исключается только она одна: правило продолжает проверять остальные файлы и имена. Чтобы выключить правило целиком, есть действие “Настроить правило…”. Находка исчезает из редактора, и проверка CI по тому же файлу (xbsl ... --baseline) перестаёт её показывать.

Файл – .xbsllint-baseline в рабочей папке (создаётся при первом исключении) либо тот, на который указывает xbsl.baseline. Причина хранится рядом с замороженной находкой, и xbsl --write-baseline сохраняет её при перезаписи:

"acme/site/Основное/Заметки.yaml": {
 "naming/number": {
  "Имя 'Заметки' в единственном числе – ...": { "count": 1, "reason": "историческое имя" }
 }
}

В режиме LSP список принятых применяет сервер, в режиме CLI – ключ --baseline. В приметы находки входит текст сообщения, поэтому файл принятых привязан к языку вывода: записывайте и проверяйте под одним xbsl.linter.lang.

LSP-режим (по умолчанию)

Расширение работает через долгоживущий сервер xbsl-lsp и не запускает CLI на каждое событие. Данные языка Элемента и индекс проекта живут в памяти, поэтому диагностика при наборе отвечает за миллисекунды. Появляется hover – карточка объекта проекта, метода или компонента формы при наведении – и дополнение по типам. Переход к определению, проектная диагностика по сохранению и quick fix работают как раньше, только быстрее. Нужен линтер с extra [lsp] (pip install "xbsl[lsp]"). Сервер ищется как xbsl-lsp в PATH, через xbsl.linter.pythonPath (запуск модулем) или явной командой xbsl.lsp.command.

Если сервера нет, расширение молча продолжает в прежнем режиме CLI. Подробности пишутся в панель вывода XBSL, а действующий режим виден в строке состояния. Выключить сервер совсем – "xbsl.lsp.enabled": false; смена настройки требует перезагрузки окна.

Шаблоны кода

Команда XBSL: шаблоны кода (xbsl.templates.manage) открывает панель управления набором. Это аналог диалога Параметры – Шаблоны в 1С:EDT: слева список, справа редактор, кнопки добавить, изменить, удалить, импортировать и выгрузить.

Набор состоит из двух частей. Встроенные шаблоны идут с инструментом, пользовательские лежат в файле .xbsl-templates.json в корне рабочей папки – путь меняется настройкой xbsl.templates.file. Пользовательский набор дополняет встроенный, а шаблон с тем же именем замещает встроенный: так правится поведение по умолчанию, ничего не ломая.

Формат файла – тот же, что у выгрузки шаблонов 1С:EDT, поэтому набор переносится между средой и редактором в обе стороны:

• XBSL: импорт шаблонов кода (xbsl.templates.import) – влить выгрузку EDT в свой файл;
• XBSL: экспорт шаблонов кода (xbsl.templates.export) – выгрузить набор в файл того же формата.

Панель не пишет файлы сама: и чтение, и запись идут через xbsl templates – тот же механизм, что у консольной команды. Поэтому набор одинаков в обоих режимах расширения, а из оболочки с ним можно работать теми же средствами (xbsl templates list / export / import).

Подстановка шаблонов при наборе работает в режиме LSP. В режиме CLI панель и обмен файлами доступны, а автодополнения по шаблонам нет.

Словарь перевода

Проект, который переводит исходники на английские написания (xbsl translate), держит свои имена, строки комментариев и строковые литералы в словаре. Словарь – это каталог xbsl-translation рядом с проектом или выше: несколько файлов yaml, тысячи записей. Команда XBSL: словарь перевода (xbsl.translate.dictionary) открывает его таблицей из пяти колонок: Вид, Ключ / Перевод, Вхождений, Где встречается, Файл словаря. Каждая запись растянута на две строки: сверху ключ и остальное содержимое строки, под ним во всю ширину – само поле перевода. Места нужно много: там стоит настоящее имя или целая строка комментария. Названия колонок служат ручками сортировки, кроме “Вида” – это просто подпись, хотя ширину и у него можно тянуть. Граница между колонками тянется мышью, ширины запоминаются между открытиями панели, а двойной клик по границе сбрасывает одну эту колонку к умолчанию.

• Поле перевода редактируется. Введённое пишет движок (xbsl translate --set) – в нужный файл и с нужной областью; очищенное поле удаляет запись. При отказе панель показывает сообщение движка и оставляет таблицу как была.
• Литерал пишется так, как он стоит в исходнике – текст между кавычками, кавычка внутри как \", обратный слеш как \\. Значение возвращается между двумя кавычками модуля, поэтому движок проверяет, что оно вообще может там стоять, и отвергает всё, что закрыло бы литерал раньше времени. Отказ показывается вместе с причиной, а поле остаётся с прежним значением.
• Два отбора: строка поиска по ключам и переводам и только незаполненные – то, что словарь ещё не покрывает. Переключатель рядом сужает таблицу до имён, до строк комментариев или до литералов.
• Предложение стоит серым прямо внутри пустого поля, как его собственная подсказка. Это платформенное написание, если движок его предлагает, иначе догадка сервиса машинного перевода (см. ниже). Галочка справа принимает предложение – щелчком или клавишей Enter, пока поле ещё пустое. Стоит начать печатать – подсказка пропадает, как и положено подсказке поля. У литерала такая подсказка бывает, только когда его текст заполнился локально из уже принятого имени (см. ниже): таблицы платформы называют имена, а не целое сообщение между кавычками.
• Место – ссылка: открывает файл исходника на этой строке. Файл словаря рядом – нет: там короткое имя, полный путь во всплывающей подсказке, щёлкать не по чему.
• Строка над таблицей считает строки, незаполненные среди них и покрытие проекта. Это то самое число, которое отдаёт xbsl translate и по которому CI останавливает сборку. Литералы посчитаны рядом, как их считает движок: в покрытие они не входят, иначе проект читал бы 100% с кириллическими сообщениями внутри.
• Длинный литерал не рвёт строку таблицы. В настоящем проекте литерал бывает в сотни символов; ячейка ключа обрезается до четырёх строк, а целиком текст показывает всплывающая подсказка.

Панель не пишет словарь сама: чтение – это xbsl translate --entries и --gaps, запись – --set. Устройство словаря – в какой файл попадёт новая запись, области, ключи ресурсов – остаётся делом движка, поэтому панель и консольная команда не могут разойтись.

Перевод прямо на находке

Правило conventions/missing-translation (по умолчанию выключено – включается в таблице правил) показывает каждое непокрытое имя, каждую строку комментария и каждый строковый литерал там, где они стоят. Его лампочка (Ctrl+.) предлагает:

• Перевести как “<написание>” – платформенная подсказка, запись в один щелчок. Действие появляется, только когда подсказка есть, поэтому у литерала его не бывает;
• Перевести “<ключ>”… – спрашивает слово, подставив в поле ту же подсказку; у литерала подсказка поля объясняет, как текст пишется между кавычками;
• Открыть словарь переводов – панель выше, отобранная по этому ключу.

Находка несёт точный ключ словаря и его вид в своих данных. Поэтому починка не угадывает ни того, ни другого по тексту сообщения – ни для имени, ни для строки комментария, которая в сообщении урезана, ни для литерала. После записи проект проверяется заново: сервер сам перечитывает словарь, перезапуск не нужен, и находка уходит.

Предложения машинного перевода

Рядом с именем или строкой комментария, которых словарь ещё не покрывает, стоит кнопка “Запросить машинный перевод”. Она просит внешний сервис (Yandex Translate или Google Translate) заполнить, что получится. Догадка появляется там же, где всегда стояло платформенное написание, – серым внутри пустого поля перевода. Щелчок по галочке или Enter записывает её ровно так же, как ручную правку поля; до этого ничего не меняется. Литерал сервису не отправляется никогда: он заполняется локально и только тогда, когда его текст целиком совпадает с уже принятым именем. Одно нажатие обходит весь проект. Ограничить обход нечем и остановить на полпути нельзя, а каждая отправленная порция это платный запрос к сервису.

Отчёт остаётся на экране. Сколько ответов пришло из кэша, сколько запрошено, сколько сервис отклонил – те же три числа, что на пять секунд появляются строкой состояния, – стоят и в сводке самой панели. Держатся они там до следующего запуска, а не только до исчезновения сообщения. Наведение на эту строку называет причину каждого отказа. Когда спрашивать было решительно не о чем, строка говорит об этом словами, а не тремя нулями; когда все предложения дали локальные совпадения литералов и сервис не спрашивали вовсе, сказано и это.

Ключ задаётся командой “XBSL: Задать ключ машинного перевода” (xbsl.translate.setKey). Она спрашивает, какой из трёх завести – ключ Yandex, каталог Yandex или ключ Google – и кладёт значение в SecretStorage, никогда в настройку и никогда в командную строку движка. Если настроено больше одного сервиса, какой из них использует --suggest, решает настройка xbsl.translation.provider.

Палитра кода

Команда XBSL: палитра кода (xbsl.choosePalette) перекрашивает синтаксис XBSL одной из популярных палитр: стиль веб-среды 1С:Элемент (красные ключевые слова, синие строки), One Dark, Monokai, Dracula, GitHub Dark. Она же возвращает цвета активной темы редактора. Выбор применяется правилами editor.tokenColorCustomizations, адресованными только областям *.xbsl, поэтому глобальная тема и другие языки не затрагиваются. Расширение управляет только своими правилами (префикс xbsl-palette) и сохраняет ваши собственные настройки.

Конструктор формы

Команда XBSL: конструктор формы (xbsl.previewForm, она же кнопка в заголовке редактора у yaml форм – файлов с КомпонентИнтерфейса) открывает панель формы. Форма зависит от собственных свойств, поэтому её структура и данные правятся там же, где она показана: слева дерево структуры, справа данные, под ними каркас формы. Между областями – перетаскиваемые разделители, их положение запоминается.

Панель – на каждую форму. Вторая форма открывается своей вкладкой рядом с первой; у каждой панели своё дерево, выделение и память раскрытия. Панель и её yaml связаны: выбор вкладки с одной стороны выводит вперёд другую, а закрытие панели закрывает yaml формы (несохранённый остаётся). Клавиши работают в самой панели: стрелки по дереву, Alt+Вверх/Alt+Вниз, F2, Delete, Ctrl+C/Ctrl+V и Ctrl+Z/Ctrl+Y.

Структура – дерево слотов и компонентов с иконкой по виду и метками линтера. Контекстное меню и клавиши: Alt+Вверх/Alt+Вниз двигают компонент, F2 переименовывает, Delete удаляет, Ctrl+C/Ctrl+V переносят фрагмент yaml. Есть оборачивание в контейнер, дублирование, фокус на поддереве и фильтр именованных. Узел перетаскивается на другой узел: контейнер принимает вложением, лист – следом за собой.

Данные – собственные Свойства: компонента и реквизиты объекта-владельца. Двойной клик или перетаскивание записи на узел структуры создаёт компонент ввода с готовой привязкой (Булево –> флажок, иначе поле ввода с Значение: =...).

Каркас формы рисует по yaml вложенные вертикальные и горизонтальные группы, надписи, поля ввода с подписями и привязками =..., кнопки (основная залита), флажки и переключатели в том виде, в каком их рисует платформа, таблицы с настоящими колонками, переключаемые вкладки (Страницы), карточки, заглушки картинок и HTML-контейнеров, панель команд формы. Неизвестные и собственные типы компонентов рисуются рамкой с подписью типа и содержимым внутри, так что ничего не пропадает. В шапке области – масштаб (−/+, колесо над регулятором и Ctrl+колесо над каркасом) и переключатель темы: светлая (вид веб-клиента платформы, по умолчанию), тёмная или тема редактора. Выбор запоминается.

Выделение общее для трёх областей. Клик по блоку каркаса и движение курсора в yaml раскрывают свёрнутые группы по пути к узлу, встают на него в структуре и наполняют панель “Свойства”. Выбранный узел светится полным цветом выделения независимо от того, где сейчас фокус. Обратный ход следует только за уже открытым yaml и сам по себе закрытый не открывает: клик по узлу структуры или по блоку каркаса переводит туда курсор, не забирая фокус. Открывает закрытый yaml только явная просьба – двойной клик по узлу структуры или Ctrl+клик по блоку каркаса. Тогда он встаёт рядом с панелью, никогда в её собственной колонке, поэтому не может оказаться позади формы, которой принадлежит.

Палитра компонентов стоит рядом с деревом метаданных и появляется, пока панель формы открыта. Двойной клик по компоненту палитры вставляет его в выделенный узел структуры. Перетащить из палитры в панель нельзя: платформа не переносит перетаскивание из своего дерева в webview. Поэтому вставка сделана кликом.

Панель свойств. Клик по элементу выделяет его и открывает отдельную панель “Свойства” – самостоятельную вкладку, которую можно перетащить вниз или в сторону. Устроена она как в веб-редакторе платформы: перечисления выпадающими списками (Компоновка, выравнивания, интервалы, ширина, вид кнопки), Растягивать* – переключателем Авто / Истина / Ложь, остальное текстом. Показывается стандартный набор компонента плюс все свойства из yaml; значения-объекты только для чтения. Правки применяются к yaml-документу точечными заменами, поэтому обычный undo работает; пустое значение или (авто) снимает свойство. Выбор элемента и каждая правка позиционируют yaml-редактор на затронутой строке, не забирая фокус. Ctrl+клик или кнопка Показать в yaml переводят в редактор – это удобно в больших формах.

Типизированные редакторы значений. Свойство-цвет открывает нативный пикер и образцы цветов, уже использованных в форме, плюс недавние: клик переиспользует оттенок. У любого однострочного значения есть переключатель “литерал / привязка”. Нажмите =, чтобы привязать свойство к данным: в режиме привязки автодополнение предлагает привязки, уже встречающиеся в форме, и реквизиты объекта-владельца формы (=Объект.Наименование). Кнопка abc возвращает к литералу.

Это каркас, а не рендер платформы. Компоновка, вложенность и подписи передаются точно, размеры и стили – приблизительно; явные цвет и размер шрифта надписей применяются.

Пресеты блоков. В области структуры команда Сохранить как пресет блока на компоненте сохраняет всё его поддерево под именем и держит его между формами и сеансами. Вставить пресет блока (в шапке палитры или в меню узла) вставляет сохранённое в текущее выделение. Это именованный постоянный вариант копирования и вставки для компоновок, которые приходится пересобирать часто. Управление пресетами блоков чистит список.

Массовая правка. Выделите в области структуры несколько компонентов и выберите Править выделенные вместе. Одно свойство задаётся или снимается сразу у всех: выберите ключ из уже используемых или введите новый, затем значение; пустое снимает свойство. Так за один шаг выравнивают ширины, переключают видимость или перепривязывают группу полей.

Обозреватель метаданных

Кнопка сворачивания в заголовке дерева (Свернуть до видов метаданных) останавливается на первом уровне: список видов остаётся виден, а раскрытые классы схлопываются. Остальные команды – создание проекта, группировка, отбор, обновление, скрытие пустых классов – лежат в меню ... того же заголовка.

Отдельная иконка 1С:Элемент на панели действий (Activity Bar) открывает дерево метаданных проекта – по образу конфигуратора платформы, но внутри VS Code.

Экспериментально. Обозреватель метаданных – экспериментальная функция, возможны ошибки и неудобства.

Дерево. Корень – проект (Проект.yaml), серым рядом Поставщик\Имя; правый клик открывает модуль приложения (Проект.xbsl). Ниже – ветка Подсистемы и категории по виду (ВидЭлемента): справочники, документы, регистры сведений/накопления, перечисления, общие модули, HTTP-сервисы, структуры, клиентские события и т.д. – каждая со своей иконкой. Пара Имя.yaml + Имя.xbsl показана одной строкой; форма объекта/списка вложена под свой объект-владелец, формы без владельца – в раздел Общие формы.

Поддеревья объектов. Справочник и документ раскрываются в Реквизиты, Табличные части, Формы; регистр – в Измерения, Ресурсы, Реквизиты; перечисление, структура и параметры работы клиента показывают значения, поля и параметры прямо под элементом, а + стоит в его строке: других разделов у них нет; HTTP-сервис – в Шаблоны URL с их методами; локализованные строки – в Локализацию: узел на каждый язык раздела (Локализация/<язык>/<Имя>.yaml), клик открывает переведённый текст. У клиента SOAP-сервиса – узел WSDL с описанием, из которого платформа порождает его тип (<Имя>.Wsdl.1.wsdl рядом с элементом): щелчок открывает файл как XML, у нескольких описаний – по узлу на файл, то же делает “Открыть WSDL” в контекстном меню клиента. У SOAP-сервиса такого узла нет – его WSDL платформа строит сама по элементу. Импортированные схемы XML (<Имя>.Wsdl.<N>.xsd) показаны в том же узле и открываются как XML.

Дерево показывает собственные счетчики ошибок и предупреждений всех файлов объекта, включая модули и запросы, и итоги пакетов, подсистем и проектов. Они работают и при выключенной problems.decorations.enabled; отметки Git сохраняются.

Панель свойств начинается с раздела документирующего комментария, если у выбранного узла есть такое место. Введите Markdown, используйте кнопки оформления и предпросмотр, затем сохраните его в текущий буфер YAML. Обычная отмена редактора остается доступной. HTML показывается текстом, небезопасные ссылки неактивны. Если исходный комментарий успел измениться, сохранение откажет и оставит черновик в панели. Раздел сворачивается, как группы свойств: пока комментария нет, он свернут, а когда комментарий задан, раскрыт; свернутый или раскрытый вручную раздел таким и остается для этого узла.

Клики. Объект или поле открывает панель свойств справа. Тип поля там – комбобокс из примитивов, ссылок <Объект>.Ссылка? и перечислений проекта, а значение можно и ввести вручную. Общий модуль открывает свой .xbsl, форма – конструктор. Правый клик добавляет Свойства, открыть описание / модуль / модуль объекта.

Модули. Контекстное меню объекта открывает каждый его модуль и создает недостающие: Создать модуль (xbsl), Создать модуль объекта (.Объект.xbsl), а у регистра и набора констант – модули записи, набора записей и ключа записи. Пункты зависят от вида, как у + рядом с элементом в представлении проекта среды разработки: у справочника есть модуль и модуль объекта, у регистра – модули типов записей, у общего модуля и формы – только свой модуль, а у виртуальной таблицы, события журнала событий, локализованных строк и навигационной команды модулей нет. Новый модуль – пустой файл рядом с описанием, названный на языке описания (Name.Object.xbsl в проекте на английском), и он сразу открывается. Табличная часть справочника и документа так же предлагает модуль своей строки: Создать модуль строки (Объект.ТабличнаяЧасть.xbsl) создает пустой Имя.ТабличнаяЧасть.xbsl рядом с описанием, и реквизиты строки в нем доступны по имени.

Панель свойств – та же, что у конструктора формы. Скалярные свойства правятся на месте: выпадающие списки для ОбластьВидимости / Окружение, переключатель Истина / Ложь, остальное текстом. Ид и ВидЭлемента – только для чтения; коллекции (реквизиты и прочее) правятся в дереве. Правки точечные, обычный undo работает; сохраните файл (Ctrl+S), чтобы дерево обновилось.

Секция “Все свойства” показывает и то, чего в файле ещё нет, – не только у самого объекта, но и у элемента любой его коллекции: реквизита, измерения, ресурса, поля структуры, реквизита табличной части, значения перечисления, параметра. Класс элемента называет сама метамодель, а где элементы разнотипные – выбирает его по имени: встроенные Код, Наименование и Владелец справочника имеют собственные классы, поэтому и наборы свойств у них свои.

Составные (вложенные) свойства – например ВыравниваниеСодержимогоПоГоризонтали { ... } – показаны, но не редактируются: правьте их прямо в yaml.

Создание объектов. В корне категории – действие “Добавить <класс>”: спрашивает имя и папку – подсистему, её пакет или корень проекта (категория под подсистемой или пакетом берёт свою папку без вопроса), пишет минимальный валидный yaml (свежий Ид; парный .xbsl у модульных видов) и открывает его. Классы показаны, даже когда их в проекте ещё нет. Доступны все классы, которые умеет создавать движок:

В группах поддерева кнопка “+” добавляет реквизит / измерение / ресурс / значение / параметр / поле / табличную часть (и реквизит табличной части). У справочника и документа есть “Добавить форму объекта”: движок генерирует форму с наполнением по реквизитам, по выбору – сразу и форму списка с колонками, и регистрирует её в Интерфейс.

У формы, подчиненной объекту или общей, и у любого другого компонента интерфейса в контекстном меню есть “Добавить свойство…” и “Добавить событие…”. Первый пункт спрашивает имя и тип: примитивный, ссылку или перечисление проекта либо тип, введенный вручную. Второй спрашивает имя и тип объекта события – СобытиеКомпонента или СобытиеСДанными<...>. Движок записывает элемент в Свойства или События компонента, а недостающую секцию ставит туда, где ее держит конструктор: Свойства перед События, События сразу после Свойства. Затем yaml открывается на новом элементе.

Шаблоны и правки yaml считает движок (xbsl 0.16+). Те же операции доступны агентам через его MCP-инструменты meta_* и любому редактору через LSP-запросы xbsl/meta* или подкоманды CLI. Дерево лишь собирает параметры и применяет присланные изменения, обычный undo работает.

Подсистемы и пакеты. Ветка Подсистемы перечисляет подсистемы проекта – каталоги первого уровня, с Подсистема.yaml или без него (клик открывает файл, если он есть), – а подсистема с пакетами раскрывается в них, вложенные под родителем. “Добавить подсистему” на этой ветке или на корне проекта создаёт в корне проекта папку с Подсистема.yaml. В группировке “По подсистемам” под подсистемой – её пакеты и объекты её корня по классам. Узел пакета в обоих местах один и тот же: каталог внутри подсистемы, число объектов серым, полное пространство имён в подсказке. Размещение отдаёт движок (xbsl/metaProjectInfo): дерево рисуется сразу и дорисовывается, когда пришёл ответ. “Создать пакет” на подсистеме или пакете спрашивает имя и первый объект пакета: каталог без объектов пакетом не считается. “Перенести в пакет…” на объекте или перетаскивание объекта на подсистему или пакет переносит его командой движка move-object: импорты и полные имена, которым нужен перенос, обновляются по всему проекту. “Переименовать пакет” переименовывает каталог и все имена, которые его называют.

Отбор по подсистемам и пакетам. Кнопка отбора в заголовке дерева – а также меню ..., корень проекта и ветка Подсистемы – открывает форму с деревом флажков: подсистемы, их пакеты с вложенностью и число объектов у каждого узла. Флажок подсистемы ставит флажки всем её пакетам. Если отмечена только часть пакетов, флажок подсистемы показывается частично, и в дереве остаются только отмеченные пакеты; так же сужается ветка Подсистемы, и числа в ней считают прошедшие отбор объекты. Когда у подсистемы или пакета есть и свои объекты, и пакеты, свои объекты отмечаются отдельным пунктом “Объекты вне пакетов”. Ничего не отмечено – отбора нет. Пока отбор включён, кнопка в заголовке закрашена, подпись проекта серым перечисляет отбор, а рядом с именем проекта стоит “Сбросить отбор по подсистемам и пакетам”. Отбор хранится для каждого проекта и переживает перезагрузку окна. Пакет, переименованный командой “Переименовать пакет”, остаётся в нём под новым именем, удалённый из него выпадает. Подсистема, добавленная при включённом отборе, не видна, пока её не отметят. Пакеты сообщает движок (xbsl/metaProjectInfo); пока он не ответил, форма показывает только подсистемы. Отобрать можно и одним щелчком. “Отобрать по подсистеме” или “Отобрать по пакету” в строке узла оставляет в дереве ровно это место, пакет вместе с вложенными, а закрашенная кнопка того же узла снимает отбор. Кнопка есть в ветке Подсистемы и в группировке “По подсистемам”.

Ресурсы и их папки. Раздел Ресурсы показывает файлы каталога Ресурсы папками с вложенностью, значком папки и числом файлов серым; у файла подписано имя и стоит значок его типа, а подсказка даёт его ключ – так он пишется в ссылке Ресурс{...}. Щелчок открывает файл, svg – в предпросмотре, который следует теме редактора. Описание каталога Ресурсы.yaml среди файлов не показывается: его открывает щелчок по узлу каталога. “Создать папку” на разделе или на папке спрашивает имя и сразу ведёт к первым файлам, потому что пустая папка не хранится: в неё переносятся ресурсы того же каталога или добавляются файлы с диска. “Добавить файлы ресурсов…” копирует выбранные файлы в папку. “Переместить в папку…” на файле или папке либо перетаскивание на папку раздела переносит ресурс командой движка move-resource, а “Переименовать папку” переименовывает папку: ключи, которые указывают на файлы, переписываются по всему проекту, обращения по вычисленной строке называются в заметке. “Удалить папку” сначала показывает все места, которые ссылаются на файлы, затем удаляет. Ресурс переносится только внутри своего каталога Ресурсы.

Где используется ресурс. “Найти все ссылки” на файле или папке показывает места, которые на них ссылаются, в панели “Ссылки” – той же, что открывает поиск ссылок самого редактора. Движок читает исходники так же, как при переносе: ключи Ресурс{...} и значения свойств-картинок, строки с путём, строки с папкой и вычисляемым именем файла. Ключ, который лежит в двух каталогах, помечен: ссылка может вести к любому из файлов. F4 переходит к следующему месту.

Статус git. Строки объектов, форм, подсистем и проекта несут SCM-декорацию файла (цвет и бейдж) как в Проводнике, сохраняя иконку вида.

Удаление. Правый клик по объекту – “Удалить объект” (с подтверждением; удаляет файлы объекта, обратимо через Undo; ссылки не обновляются – оборванные покажет линтер).

Созданный объект – это заготовка в файлах, он не деплоится сам. Невалидный всплывёт только при следующем деплое, откат ловит elemctl, рабочие файлы при этом не портятся.

Пример: демо-приложение деревом и деплой на 1cmycloud.com

Дерево умеет собрать рабочее приложение с нуля (yaml генерируют те же шаблоны, что и дерево):

1. Открыть папку с файлом проекта – в дереве появится корень-проект.
2. Подсистемы → “+” → Добавить подсистему → Основное.
3. Справочники → “+” → Добавить справочник → Товары (подсистема Основное); так же Категории.
4. Под Товары → Реквизиты → “+” → Добавить реквизит → Цена, Артикул.
5. Перечисления → Добавить перечисление → СтатусТовара; + на нём → ВНаличии, ПодЗаказ.
6. Задеплоить: elemctl deploy --app-id <app> --project-dir <папка проекта> --output <tmp> (создать приложение заранее: elemctl apps ensure <app> --latest-build --wait).

Отчёт деплоя на 1cmycloud.com – ok: true появляется, только когда сборка действительно применилась:

собран архив <проект> 1.0-N.xasm (версия 1.0-N)
сборка загружена, применение запущено, ждём стабилизации приложения...
приложение в статусе Running, проверяем фактическое применение...
проверка пройдена: сборка применена
{
  "uri": "https://<хост>.1cmycloud.com/applications/<app>",
  "status": "Running",
  "applied-version": "1.0-N",
  "applied": true,
  "uri-status": 200,
  "problems": [],
  "ok": true
}

applied: true и ok: true означают, что сборка реально применилась. Справочники Товары и Категории и перечисление СтатусТовара, собранные деревом, открываются в стандартном интерфейсе; демо не требует OIDC и входа.

Документация

Отдельный контейнер Документация (1С:Элемент) на панели действий показывает справку платформы так, как её показывает сайт документации. Собрана она из вашего дистрибутива, поэтому совпадает с вашей версией платформы и работает без сети.

Дерево. Курируемое “Содержание”, совпадающее с сайтом: руководства разработчика и администратора, справочник типов (Стд::Коллекции → Массив → …), свойства элементов проекта и компонентов интерфейса, схема процесса интеграции, язык запросов и глоссарий. Строится из данных сайдбара самого дистрибутива, поэтому структура как на сайте. Клик по узлу открывает страницу.

Поиск. Кнопка поиска в заголовке вида (команда XBSL: поиск по документации) ищет полнотекстово по всему справочнику и руководству; выбор из списка открывает страницу.

Страница. Открывается вкладкой редактора сбоку и не забирает фокус: очищенная статья с кодом (у примеров – кнопка Копировать), таблицами и картинками и ссылкой Первоисточник на ту же страницу на сайте. Разделы страницы вложены в её узел дерева, внутренние ссылки ведут к другим страницам в этой же вкладке, а при открытии страницы дерево “Содержание” на неё позиционируется.

Документация по символу. Правый клик на типе или переменной в .xbsl – XBSL: документация по символу – открывает её страницу. Для типа сразу открывается страница справочника. У отдельного члена типа своей страницы нет, поэтому открывается страница объявившего его типа, прокрученная к блоку члена: Массив.Размер ведёт на страницу предка, объявившего метод. Когда одно имя объявлено несколькими неродственными типами, предлагается выбор из этих типов, а строкой под каждым идёт блок члена с его страницы. У прочих имён без своей страницы список кандидатов ранжируется по приёмнику перед точкой: Задание.Настроить отдаёт предпочтение страницам запланированного задания, а не топику руководства.

Куда ведут остальные входы. Подсказка при наведении на имя в .xbsl показывает описание и ссылку Документация: над членом типа это сигнатура вызова и что он делает, и ссылка открывает страницу сразу на нём. В конструкторе форм у элемента палитры есть действие Открыть документацию, краткое описание видно и в подсказке. Оба открывают страницу в этой же панели, поэтому читать про незнакомый компонент можно не уходя из редактора.

F12 отступает на страницу. Переход к определению отвечает по индексу проекта, поэтому у члена платформы прыгать некуда: там клавиша открывает страницу документации вместо сообщения о промахе. Настоящее определение всегда выигрывает, а когда нет ни того ни другого, о промахе сообщает VS Code, как обычно.

Данные даёт LSP-сервер линтера, поэтому нужен режим LSP и база документации, собранная из вашего дистрибутива (см. README линтера). В обычном режиме (CLI) вид сообщает, что документация доступна в режиме LSP.

Деплой на стенд

Команда XBSL: деплой на стенд (elemctl) (xbsl.deploy, она же кнопка-облачко в заголовке дерева метаданных) запускает elemctl deploy терминальной задачей, после диалога подтверждения с точной командной строкой. Деплоится проект целиком, а не открытый файл. Шаги обычные: сборка, загрузка, применение и проверка того, что применение состоялось. При сбое применения платформа молча откатывает приложение на прежнюю сборку, продолжая отвечать Running; elemctl этому статусу не верит и завершается ненулевым кодом.

Рабочий каталог – рабочая папка. Подключение и цель elemctl читает из своего .env (ELEMENT_BASE_URL, ELEMENT_CLIENT_ID/SECRET, ELEMENT_APP_ID, ELEMENT_PROJECT_ID). Заданный xbsl.projectRoot передаётся как --project-dir. Отсутствующий elemctl предлагается установить прямо из сообщения об ошибке.

Отладка

Отладка приложений 1С:Элемент идёт в обычном VS Code, без веб-среды на Theia: точки останова, стек вызовов, сцепляющий клиентские и серверные кадры, значения переменных, пошаговое выполнение. Расширение и здесь тонкое: оно запускает штатный debug-адаптер платформы (Java, протокол DAP) и получает координаты сессии через elemctl (Console API /actions/debug). Идентификатор сессии, сгенерированный на клиенте, сшивает адаптер и отлаживаемое приложение через сервер отладки платформы.

До версии 0.57 это было отдельное расширение XBSL Debug (keyfire.xbsl-debug). Теперь оно часть этого. Деплой и отладка адресуют одно и то же приложение одним и тем же elemctl, а от разделения выходило только одно: реквизиты спрашивались дважды. Настройки старого расширения (xbslDebug.*) по-прежнему читаются, прежняя конфигурация продолжает работать.

С чего начать. Выполните XBSL: настроить отладку 1С:Элемент (xbsl.debug.setup) из палитры команд. Мастер проверит Java, каталог адаптера и elemctl, что сможет – починит на месте и предложит создать launch.json. Дальше откройте папку с исходниками, поставьте точку останова в .xbsl и нажмите F5: приложение откроется в браузере с параметрами отладки, а выполнение остановится на вашей точке.

Что нужно:

1. JDK 17+ (21 тоже подходит) – java -version.
2. elemctl >= 0.5 (команды apps debug и debug-adapter) с настроенным .env в корне исходников. Отсутствующий elemctl предлагается установить из сообщения об ошибке и из мастера.
3. Debug-адаптер платформы. Возьмите его из своего дистрибутива 1С:Элемент (.../@1c-appengine-plugin/bin/debugger – каталог с подпапкой repo, где лежат jar-файлы) и задайте xbsl.debug.adapterPath. Адаптер – проприетарный код 1С, в расширение он не входит.
4. Отладка, включённая на сервере приложения – на облачных стендах обычно уже включена.

Исполняемый файл elemctl и идентификатор приложения общие с деплоем (xbsl.deploy.elemctlPath, xbsl.deploy.appId). Реквизиты Console API живут в .env корня исходников, а не в настройке: elemctl читает их сам. launch.json необязателен; его атрибуты – appId, envFile, authMode и workspace.

Как привязываются точки останова. Сервер отладки опознаёт модуль по пути относительно корня исходников в форме <Поставщик>/<Имя>/<путь в проекте>.xbsl с прямыми разделителями. Поэтому исходники должны лежать в каталоге <Поставщик>/<Имя>/, совпадающем с Проект.yaml, а рабочая папка – указывать на каталог, который его содержит. Этот корень расширение определяет от открытой папки само, так что годится и корень репозитория, и подпапка.

Обойдённая ошибка платформы. Раскрытие структуры в панели переменных на клиентском кадре вешало отлаживаемое приложение и рвало сессию. Причина: DAP-запрос variables без поля filter – ровно такой панель переменных VS Code шлёт для небольших значений – роняет среду выполнения JS в приложении, тогда как запрос с фильтром работает штатно. Расширение переписывает каждый запрос без фильтра в запросы с фильтром (named + indexed, счётчики берутся из ответа родителя) и склеивает результаты. Дерево значений раскрывается нормально и на клиентских, и на серверных кадрах. Обход безусловный, настройки у него нет: выключение не даёт ничего, кроме оборванной сессии.

Команды

• XBSL: новый проект 1С:Элемент (xbsl.project.new) – мастер создания проекта (см. выше).
• XBSL: проверить весь проект (xbsl.lintProject) – проверить всю рабочую папку.
• XBSL: структурный поиск по формам (xbsl.forms.search) – поиск компонентов по типу и свойствам (см. выше).
• XBSL: перезапустить линтер (xbsl.restartLinter) – сбросить и перепроверить открытые файлы.
• XBSL: палитра кода (xbsl.choosePalette) – выбрать палитру подсветки XBSL (см. выше).
• XBSL: шаблоны кода (xbsl.templates.manage), импорт (xbsl.templates.import) и экспорт (xbsl.templates.export) – набор шаблонов и обмен выгрузкой EDT (см. выше).
• XBSL: деплой на стенд (elemctl) (xbsl.deploy) – развернуть проект на стенде (см. выше).
• XBSL: конструктор формы (xbsl.previewForm) – панель активной yaml-формы (см. выше).
• XBSL: поиск по документации (xbsl.docs.search) и документация по символу (xbsl.docs.showForSymbol) – вид Документация (см. выше).
• Команды обозревателя метаданных (xbsl.metadata.*) вызываются из самого дерева и его контекстных меню: свойства, добавить объект / поле / подсистему, форму объекта, отбор по подсистемам и пакетам, удалить объект, обновить. См. Обозреватель метаданных.

Обратная связь и ошибки

Расширение активно развивается, поэтому возможны ошибки и шероховатости, особенно в обозревателе метаданных и конструкторе форм. Если что-то работает не так, пожалуйста, сообщите об этом в issues проекта на GitHub. По возможности приложите шаги воспроизведения и версии расширения и движка из строки состояния.

https://github.com/keyfire/xbsl/issues

VS Code также предлагает Report Issue на странице расширения (по ссылке bugs из манифеста).

Разработка

npm install
npm run compile          # сборка esbuild -> dist/extension.js
npm run check            # проверка типов tsc
npm test                 # модульные тесты чистых ядер (обычный Node, без тестового движка)
npm run package          # сборка .vsix (через @vscode/vsce)

F5 в VS Code запускает Extension Development Host с загруженным расширением.

Лицензия

MIT – см. репозиторий.