Всего три года назад для программиста на стэке технологий от Microsoft не существовало проблемы выбора иструмента разработки. Сегодня картина поменялась и Visual Studio Code выступает в качестве реальной альтернативы классическому Visual Studio и предостовляет функциональность которая ставит его гораздо ближе к IDE, чем к текстовому редактору. Бесплатный, кросс-платформенный и с открытым исходным кодом, этот редактор пользуется заслуженным уважением коммьюнити разработчиков ПО.
Данная статья описывает наш опыт в оценке возможности миграции одной из функций нашего внутреннего VS плагина на платформу Visual Studio Code.
TL;DR;Если вы начинаете новый проект среднего размера, я смело могу рекомендовать Visual Studio Code в качестве основного инструмента разработки команды. Особенно если в команде используются разные операционные среды. Если же вы поддерживаете большой проект и инвестировали в разработку собственных расширений для VS, то классическая версия всё еще вне конкуренции.
Классический Visual Studio заслуженно считается одним из лидеров в сфере IDE и даже самая простая его версия включает большинство функций необходимых разработчику. Если же установить must-have плагины (например ReSharper и WebEssentials), то будет трудно найти сравнимый продукт. В добавок к этому, подписавшись на MSDN (можно бесплатно через одну из spark программ, если вы удовлетворяете её критериям) вы получите доступ к ресурсам которые помогут привести ваш проект к успеху.
Многие тысячи доступных плагинов для VS делаю вашу работу более комфортабельной и продуктивной. Если же вам потребуется функциональность специфичная для вашего проекта, то VS предоставляет очень разнообразное и продуманное API для воплощения вашей задумки.
Семь лет назад, когда мы начали работать над новым проектом, мы решили сформировать набор расширений, который бы помог нашим разработчикам в работе с этим проектом. Если мы взглянем назад и проанализируем результаты работы, то можно сказать что если бы этот набор плагинов был бы человеком, то он бы был одним из наиболее продуктивных и незаменимых вкладчиков в дело успеха проекта.
Но в последнее время, всё чаще мы слышим пожелания (особенно от ребят из не MS-центричного мира) что пора всерьез рассмотреть возможность миграции некоторых из функций этого плагина на платформу VS code.
В качестве подопытного кролика было решено реализовать одну из наиболее простых функций, которая показывает сообщение разработчику при открытии или начале редактирования файла, который содержит комментарии в определенном формате.
Этот плагин был изначально разработан для поддержки работы с авто-сгенерированным кодом. В прошлом, если разработчик не обращал внимание на предупреждения в начале файла, то его изменения терялись при перегенерации исходного кода, а этот плагин позволял уведомлять программиста в момент начала изменений кода.
Со временем были добавлены дополнительные функции которые оказались очень полезны не только для авто-сгенерированным кода. Например если добавлялся подобный комментарий в #range выражение, то уведомление показывалось только для этой области или в добавок к уведомлению, можно было запретить редактирование этого фрагмента по некоторым критериям, например по членству в группе “seniors” в нашем AD.
Определившись с выбором мы запланировали и выделили необходимые ресурсы для его реализации в одном из технических спринтов.
Шаги которые мы выполнили при миграции этого расширения:
1. Установил VS code и nodejs пакеты необходимые для генерации расширения.
Примечание: Установите последний nodejs. У меня возникли странные проблемы в связи с тем что установленный nodejs был не первой свежести. После обновления, всё заработало как положено.
2. Измените тип активации на все возможные события (*) в файле package.json
"activationEvents": [
"*"
],
3. Главный метод активации расширения
export function activate(context: vscode.ExtensionContext) {
context.subscriptions.push(new EditWatcherExt());
}
4. Подписываемся на события которые нас интересуют используя методы из vscode.workspace
code.visualstudio.com/docs/extensionAPI/vscode-api#_workspace
this._onOpenTextDocument = vscode.workspace.onDidOpenTextDocument(e => this.showMessages([e]));
this._onCloseTextDocument = vscode.workspace.onDidCloseTextDocument(e => this.OnCloseTextDocument(e));
5. Отображаем сообщения используя методы из vscode.window code.visualstudio.com/docs/extensionAPI/vscode-api#_window
private displayMessages(msgs: MessagesData) {
if (msgs.Console.length > 0) {
console.log(msgs.Console.join('\r\n'));
}
if (msgs.Info.length > 0) {
vscode.window.showInformationMessage(msgs.Info.join('\r\n'));
}
if (msgs.Warn.length > 0) {
vscode.window.showWarningMessage(msgs.Warn.join('\r\n'));
}
if (msgs.Error.length > 0) {
vscode.window.showErrorMessage(msgs.Error.join('\r\n'), { modal: true });
}
if (msgs.StatusBar.length > 0) {
if (msgs.StatusBarTimeout > 0)
vscode.window.setStatusBarMessage(msgs.StatusBar.join('\r\n'), msgs.StatusBarTimeout);
else
vscode.window.setStatusBarMessage(msgs.StatusBar.join('\r\n'));
}
}
6. Не забыть освободить ресурсы.
dispose() {
this._onOpenTextDocument.dispose();
this._onCloseTextDocument.dispose();
this._onTextDocumentChanged.forEach(e => e.dispose());
}
Вы можете отписаться от события в любое время вызвав dispose метод.
Суммируя опыт миграции:
— Достигли ли мы поставленных целей?
Частично; не все наши требования могут быть выполнены в VS code без значительных затрат времени и ресурсов.
— Будем ли мы мигрировать другие расширения под платформу VS code?
Скорее всего нет. Несмотря на то что VS code всё более и более популярен, но мы не смогли увидеть значительных преимуществ которые бы окупили усилия на миграцию. Когда мы начнём работу над новым проектом, то мы ещё раз вернёмся к этому вопросу.
Комментарии от команды программистов по процессу разработки и возможностям VS code
- Нам показалось что входной уровень для начала разработки под VSC ниже по сравнению с классическим VS. Мы потратили примерно четыре часа с начала установки VSC до создания минимально функциональной версии. Доработка до окончательной версии заняла ещё столько же.
- Иерархия API и возможности расширения довольно логичны и хорошо продуманны.
- Документация на твёрдую четвёрку, но форматирование в стиле всё что возможно поместим на одну страницу, лично мне кажется не лучшим выбором, особенно если в следующих версиях будет её расширение.
- Примеры из документации покрывают базовые случаи, но было бы не плохо рассматривать более сложные сценарии. Но так как этот редактор с отрытым кодом, то и большинство расширений тоже открываю свой код и вы можете посмотреть примеры на любые темы.
- Скорость работы расширения приемлемая и то что расширения работают в отдельном процессе положительно сказывается на стабильности и отзывчивости редактора.
- К текущему моменту, возможности глубокой интеграции с редактором существенно ниже по сравнению с классическим VS и реализация кажущихся простыми задачами, может потребовать больше усилий.
- Использование webview позволяет реализовать многие из задач, но ограничение в возможностях интеграции являются сдерживающим фактором как. Следование общему UI стилю, также требует дополнительных усилий и самоконтроля.
Полезные ссылки
code.visualstudio.com/docs/extensions/overview — описание процесса разработки расширений для VS code и пошаговые инструкции для создания вашего первого расширения.
github.com/Microsoft/vscode/tree/master/extensions — репозиторий расширений от компании Microsoft. Много расширений отличного качества, идеальные примеры при создании вашего собственного расширения.
marketplace.visualstudio.com/VSCode — магазин расширений для VS code. Поищите расширение которое затрагивает функциональность похожую на ту что вы планируете реализовать и в большинстве случаев там будет ссылка на репозиторий с исходным кодом.
github.com/eugenebb71/EditWatcher – репозиторий нашего плагина.
Надеюсь, что статья послужит вам стимулом попробовать реализовать собственные идеи и задумки. Не стесняйтесь задавать вопросы и высказывать предложения.
К сожалению мои литературные способности заставляют желать лучшего, поэтому заранее приношу извинения любителям и ценителям языка. Все ваши подсказки и изменения к лучшему будут приняты с благодарностью.
Умножайте всё вышесказанное по поводу языка, на коэффициент 8.3
Three years ago, you would not have a second thought what IDE to use when you start working on a .Net application, but today it is difficult not to notice a tectonic shift in an IDE/editor of choice for small/middle size projects, especially those being developed using set of mixed platforms. The new name in a town is Visual Studio Code – free, open source and cross-platform editor with set of features so rich that many IDE would envy it.
This article is about our evaluation of feasibility of migration a feature of our internal VS plugin to VSC.
TL;DR;If you are starting a new small/mid-size project, then I would definitely consider VS code, though if you are working on a large scale project or invested a lot of time/money into original VS environment, then I would stay with it.
Original Visual Studio was a very stable and mature enterprise-level product. Even plain out-of-box version covered most of the needs of an average developer and after installing few «must-have» plugins (like ReSharper and WebEssentials) it would be by far, out of reach by any competing product. For a low price of $539 per year, per developer you would get access to MSDN subscription and enjoy power that is provided by one of largest and the most advance technological companies. Support, free licenses, Azure subscriptions and more. Definitely worth it, if you are working on a large scale project.
Thousands and thousands VS plugins and extensions make your working experience pleasant, comfortable and productive. And if you need something specific for your project and/or environment, there always was set of powerful and well-thought extension points at your disposal.
That was a route that we have chosen for our project more than seven years ago and so far, had no regrets. We have created our own plugin that supports specific needs and requirements for our project and during these years it grown to be helpful assistant in day-to-day tasks and if it would be a person, you might consider him being one of the most productive and essential member of our team.
But recently, there are voices (mostly for guys from other side of an aisle) that maybe it is time to accept the reality and invest into migrating some of the project VS plugins to VSC as well.
As a Guinea pig for migration effort we have chosen a plugin feature that allows notifying a developer if he/she opens/edits a file that has a comment in specific format.
This plugin proved to be very useful for our project that has a lot of auto-generated code. In the past, from time to time, someone would miss a warning at the top of a file and make changes to such files and as a result waste time making changes that would be lost the next time the source code regenerates.
Since then, we have added couple extra features that make it useful even outside of an original idea of controlling auto-generated files. For example, you can include that type of comments to a #range area and someone would start editing code inside the range, they would get a message or even be prohibited from making changes, based on a criteria like membership in an AD group “seniors” and etc. Or adding an extra sign to an icon in solution explorer that would make files that require special attention easily noticeable.
Here are steps that I took:
1. Installation of VS code and nodejs packages needed to jump-start your plugin.
Note: make sure you have the latest nodejs installed. I had one from some time ago and it gave me some weird errors when I was trying to use yo. After update everything was smooth and fast.
2. Updated package info in package.json file to change activation on «everything»
"activationEvents": [
"*"
],
3. Main entry points for your extension activation
export function activate(context: vscode.ExtensionContext) {
context.subscriptions.push(new EditWatcherExt());
}
4. Subscribed for document related events using workspace methods code.visualstudio.com/docs/extensionAPI/vscode-api#_workspace
this._onOpenTextDocument = vscode.workspace.onDidOpenTextDocument(e => this.showMessages([e]));
this._onCloseTextDocument = vscode.workspace.onDidCloseTextDocument(e => this.OnCloseTextDocument(e));
5. Displayed notifications using window methods provided by code.visualstudio.com/docs/extensionAPI/vscode-api#_window
<source lang="typescript">private displayMessages(msgs: MessagesData) {
if (msgs.Console.length > 0) {
console.log(msgs.Console.join('\r\n'));
}
if (msgs.Info.length > 0) {
vscode.window.showInformationMessage(msgs.Info.join('\r\n'));
}
if (msgs.Warn.length > 0) {
vscode.window.showWarningMessage(msgs.Warn.join('\r\n'));
}
if (msgs.Error.length > 0) {
vscode.window.showErrorMessage(msgs.Error.join('\r\n'), { modal: true });
}
if (msgs.StatusBar.length > 0) {
if (msgs.StatusBarTimeout > 0)
vscode.window.setStatusBarMessage(msgs.StatusBar.join('\r\n'), msgs.StatusBarTimeout);
else
vscode.window.setStatusBarMessage(msgs.StatusBar.join('\r\n'));
}
}
6. Remember to dispose unneeded resources.
dispose() {
this._onOpenTextDocument.dispose();
this._onCloseTextDocument.dispose();
this._onTextDocumentChanged.forEach(e => e.dispose());
}
You can unsubscribe from an event at any time as well, by calling the dispose method.
Summary of our migration experience
— Was the exercise useful?
Yes.
— Have we achieved our goal?
Partially, not all of our requirements could be met by VS code extension API.
— Are we going to migrate our other plugins?
VS code here with us to stay, but for now, we will stick with original VS. There are no immediate benefits for our project that would outweigh pain of changes. Especially for our distributed team. If you start new project or money are tight, VS code is a strong candidate for being editor/IDE for your team.
Bullet points for development process and VS code extension capabilities from our team/project needs.
- Entry level for starting development of plugins for VSC is somewhat lower in compare with original VS. The time from start of VSC installation till first functioning PoC was around four hours. Even though nodejs and typescript is not my strongest areas.
- Hierarchy and design for extension points is well-thought and logical.
- Documentation is solid, but “everything-on-one-page” vscode API format is not the best choice, especially if it will continue to grow.
- Examples are good, but would like to see more of them, especially more complex scenarios with explanations of design decisions and etc. Luckily there are a lot of great open-sources extensions that could be considered as a source of great examples.
- Performance is decent and decision to run extensions inside dedicated “extension host” positive for stability and responsiveness of the editor.
- At this point, at the first look it seems that VSC provides less control and options in compare with original VS. It may take more effort to implement seemingly simple tasks.
- Using webview provides you with powerful way to implement your idea, but limits integration points and requires self-control to follow UI guidelines.
Some of the useful links
code.visualstudio.com/docs/extensions/overview — overview of the VS code extensions development processes and step-by-step instructions to take you through your first extension.
github.com/Microsoft/vscode/tree/master/extensions — Microsoft’s VS code extensions repository
marketplace.visualstudio.com/VSCode — VS code marketplace. Search for an extension that touches similar areas the one you plan to develop and see if they have a link to a repository with source code. Many of them do.
github.com/eugenebb71/EditWatcher – our plugin repository
Комментариев нет:
Отправить комментарий