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). Мне мозолят глаза расширения, специфичные для Реакта, в проекте с Ангуляром, и наборот. Как решить данную задачу с помощью «Профилей»?
До июльского релиза это было бы так:
-
Создал профиль («Шестерёнка -> Профили -> Создать профиль») из корневого для каждого из стеков;
-
Отключил соответствующие расширения.
А теперь появляется проблема. Стоит только мне обновить, например, какую-то настройку в профиле по умолчанию VS Code, она не применится для созданных мною профилей.
А в случае «Частичных профилей» ты делаешь так:
-
Нажал «Создать профиль»;
-
Выбрал группы настроек, которые он будет менять;
-
Отключил соответствующие расширения.
Настройки, которые профиль не меняет, подтягиваются из профиля по умолчанию. Если в профиле по умолчанию что-то меняется, то оно автоматом отразится и на «дочернем» профиле. Вот это другое, вот это я понимаю, наследование!
Но это не наследование. Это пересечение/наложение множеств настроек между профилем по умолчанию и кастомным. Только та группа настроек (например, расширения), за которую отвечает кастомный профиль, становится независимой от дефолтного. В случае, если вы делитесь своим частичным профилем с кем-то еще, то частичный будет тянуть все настройки, кроме расширений, из профиля по умолчанию уже того человека, с кем вы поделились. Если бы это было жесткое наследование, то данную фичу не удалось бы реализовать настолько гибко.
Как еще можно улучшить фичу?
Если подумать дальше, то можно реализовать следующее:
-
Еще более гибкий список настроек: например, для расширений указать обязательные к включению и отключению расширения, а остальные пусть тянутся из профиля по умолчанию. Это можно применить вообще к любому типу настроек. Тогда частичные профили будут всего лишь набором белых и черных списков, что при импорте профиля позволит не ломать существующий набор настроек полностью, только отключать и включать нужные. Это явно лучше, чем захардкоженные настройки, пусть и поделенные на группы;
-
Автоматическое распознавание стека проекта (если это не workspace или монорепо) и отключение расширений из конкурирующих сущностей (ЯП, библиотек, иных зависимостей). Открыл проект на .NET — и все экстеншны, хоткеи и тест-сценарии из мира Java больше не кушают оперативку впустую;
-
Репозиторий профилей на манер репозиториев пакетного менеджера. Например, пользователь VS Code запилил частичный профиль; сконфигурировал какой-нибудь декларативный детектор метаинформации, который определяет, на какой тип проекта подходит данный профиль; залил частичный профиль в репозиторий; VS Code при открытии проекта с такими-то метаданными (наличие определенных файлов с таким-то паттерном в имени, типы файлов, структура, какие-то определенные данные в конфигах) предлагает скачать и установить профиль, созданный этим пользователем.
Юзкейс уже есть: например, я сконфигурировал профиль для (относительно) редкого типа проекта — разработка юзерскрипта для Tampermonkey на Deno. У меня есть желание поделиться этим профилем со всем миром, но хочу сделать так, чтобы он почти ничего не менял у конечного пользователя, просто отключал некоторые расширения, добавлял горячие клавиши, а остальное не трогал.
Сейчас такое невозможно сделать, потому что если частичный профиль меняет только список расширений — то этот список приколочен к профилю гвоздями. Без белых и черных списков (см. пункт 1). Ну, и самого такого реестра профилей сейчас нет, конечно.
Надо бы все эти фантазии по Фрейду написать им в issues…
Где выводы, Лебовски?
«Профили» использовать нужно, факт есть факт. Потратить минуту на организацию отдельного профиля, специфичного для данного проекта, думается, каждый сможет. Именно сейчас, с июльским обновлением 1.81, они пригодятся вам как никогда!
ссылка на оригинал статьи https://habr.com/ru/articles/761384/
Добавить комментарий