«Профили» в VS Code, оказывается, весьма нужная фича

от автора

TL;DR В статье рассказывается о том, что такое «Профили» (Profiles) в VS Code, какие задачи решает эта фича и как ею пользоваться.

Дисклеймеры

Общий дисклеймерО личности автораОтказ от ответственностиОб использовании ChatGPT

Аннотация

В данной заметке рассказывается, зачем вообще такая штука, как «Профили», нужна. В итоге оказалось, что фича нереально нужная и востребованная, если человек пользуется данным редактором для сильно различающихся проектов. Например, один проект для фронтенда, другой для бекенда на отличном от «фронтового» языке программирования, третий вообще не проект для разработки, а тексты на LaTeX/markdown… Функция «Профили» помогает человеку подстраивать редактор индивидуально для каждого проекта. В статье также расписываются преимущества «Частичных профилей» и их концепция, а также идею по развитию функционала.

Введение

Microsoft зарелизила «Профили» в свой фирменный редактор Visual Studio Code еще в январьском обновлении 1.75. Я тогда дал себе заро́к их протестировать, но благополучно забыл. Вдогонку к первому релизу этой фичи разработчики доработали этот функционал и представили «Частичные профили» в последнем июльском обновлении. В этот раз я вспомнил про своё обещание и решил их использовать. Исхожу из своего опыта и понятия об этой функции редактора.

Пример переключения между профилями

Пример переключения между профилями

Профили

Поначалу читатель спросит: «Не, а в чём проблема? Ты просто создаешь профиль под определенный стек, меняешь набор расширений и настроек, перезагружаешь редактор и всё на этом!». На самом деле читатель скорее прав, чем нет. Скрытый призыв данной статьи в том, что данный функционал использовать надо. При условии, что вы не пишите в VS Code один-единственный проект за всю жизнь.

Профиль отвечает за практически все настройки редактора — регулирует набор расширений, горячих клавиш, сниппетов, задач по отладке и непосредственно настроек не только редактора, но и его расширений. Профиль можно применить на несколько проектов, и только от вас зависит набор профилей и настроек в них.

Подробнее о «Profiles» в документации. В общем, я был удивлён, как же я раньше жил без этого функционала? И задумался…

Как мы жили без них раньше?

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

Настройки рабочей зоны

Настройки рабочей зоны

Не знаю, хорошо я делаю или нет, но всё-таки я решился коммитить все конфиги VS Code, которые применяются к проекту, прямо в Git.

С одной стороны — это загаживание репозитория. Главный пассивно-агрессивный аргумент в моём стиле: «Ну, давайте тогда в репу лить конфиги вообще всех IDE, которые когда-либо открывали этот проект!».

С другой — наличие конфигов для IDE и редакторов сразу в проекте ускоряет быстрый старт для новичка. Особенно с файлом .vscode\extensions.json, который сразу рекомендует поставить расширения, необходимые для работы в проекте. Согласны?

Означает ли это, что теперь можно отказаться от индивидуальных для проекта настроек в директории .vscode? Нет. Профили прекрасно сочетаются с ними.

Концепция «Частичных профилей»

Частичные профили

Частичные профили

С релизом «Partial profiles» фича, наконец, стала полностью завершенной.

Следите за руками:

Допустим, сейчас май 2023 года, спина не болит, рубль не пробил потолок в 100 за доллар, и у меня сейчас открыты проекты на Angular и на React (Node/Deno, Fastify/Express, Nest/Koa, you name it). Мне мозолят глаза расширения, специфичные для Реакта, в проекте с Ангуляром, и наборот. Как решить данную задачу с помощью «Профилей»?

До июльского релиза это было бы так:

  1. Создал профиль («Шестерёнка -> Профили -> Создать профиль») из корневого для каждого из стеков;

  2. Отключил соответствующие расширения.

А теперь появляется проблема. Стоит только мне обновить, например, какую-то настройку в профиле по умолчанию VS Code, она не применится для созданных мною профилей.

А в случае «Частичных профилей» ты делаешь так:

  1. Нажал «Создать профиль»;

  2. Выбрал группы настроек, которые он будет менять;

  3. Отключил соответствующие расширения.

Настройки, которые профиль не меняет, подтягиваются из профиля по умолчанию. Если в профиле по умолчанию что-то меняется, то оно автоматом отразится и на «дочернем» профиле. Вот это другое, вот это я понимаю, наследование!

Но это не наследование. Это пересечение/наложение множеств настроек между профилем по умолчанию и кастомным. Только та группа настроек (например, расширения), за которую отвечает кастомный профиль, становится независимой от дефолтного. В случае, если вы делитесь своим частичным профилем с кем-то еще, то частичный будет тянуть все настройки, кроме расширений, из профиля по умолчанию уже того человека, с кем вы поделились. Если бы это было жесткое наследование, то данную фичу не удалось бы реализовать настолько гибко.

Как еще можно улучшить фичу?

Если подумать дальше, то можно реализовать следующее:

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

  2. Автоматическое распознавание стека проекта (если это не workspace или монорепо) и отключение расширений из конкурирующих сущностей (ЯП, библиотек, иных зависимостей). Открыл проект на .NET — и все экстеншны, хоткеи и тест-сценарии из мира Java больше не кушают оперативку впустую;

  3. Репозиторий профилей на манер репозиториев пакетного менеджера. Например, пользователь VS Code запилил частичный профиль; сконфигурировал какой-нибудь декларативный детектор метаинформации, который определяет, на какой тип проекта подходит данный профиль; залил частичный профиль в репозиторий; VS Code при открытии проекта с такими-то метаданными (наличие определенных файлов с таким-то паттерном в имени, типы файлов, структура, какие-то определенные данные в конфигах) предлагает скачать и установить профиль, созданный этим пользователем.

    Юзкейс уже есть: например, я сконфигурировал профиль для (относительно) редкого типа проекта — разработка юзерскрипта для Tampermonkey на Deno. У меня есть желание поделиться этим профилем со всем миром, но хочу сделать так, чтобы он почти ничего не менял у конечного пользователя, просто отключал некоторые расширения, добавлял горячие клавиши, а остальное не трогал.

    Сейчас такое невозможно сделать, потому что если частичный профиль меняет только список расширений — то этот список приколочен к профилю гвоздями. Без белых и черных списков (см. пункт 1). Ну, и самого такого реестра профилей сейчас нет, конечно.

Надо бы все эти фантазии по Фрейду написать им в issues…

Где выводы, Лебовски?

«Профили» использовать нужно, факт есть факт. Потратить минуту на организацию отдельного профиля, специфичного для данного проекта, думается, каждый сможет. Именно сейчас, с июльским обновлением 1.81, они пригодятся вам как никогда!


ссылка на оригинал статьи https://habr.com/ru/articles/761384/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *