It was a few months ago when we set out to provide a great code editing experience for NativeScript developers. We came down in favor of Visual Studio Code mostly because it is a contemporary, cross-platform, feature-rich and highly extensible code editor which became extremely popular among software developers.
Since then we have been actively developing the NativeScript extension for Visual Studio Code which comes with Intellisense, interactive debugging and integration with device emulators, providing the most feature complete environment for NativeScript development. Along the way, we documented some of our biggest a-ha moments to help the developer community wishing to build VS Code extensions.
The VS Code extension architecture gives us the ability to provide a NativeScript-specific debug adapter. From a technical perspective, the debug adapter is a standalone executable that adapts the abstract VS Code Debug Protocol to a concrete debugger protocol. On every debug session, VS Code loads the debug adapter in a brand new process, which means that from within the debug adapter’s code we have no access to the VS Code API available in the extension host process.
This is a bit tricky because in case you are using node as a runtime for your debug adapter, it is expected to have common code loaded in both processes. When designing such shared modules keep this in mind:
1. Minimize dependencies on the VS Code API, because it is callable only from the extension host process.
2. If such a module executes some logic when required (e.g., sending data to server), it will be executed many times – once in the extension host process and once for every debug session in the debug adapter process. If this is not what you want, avoid executing code on module loading.
In case you want to share some data between both processes or the debug adapter needs access to the VS Code API (e.g., to show a message box), consider using one of the well-known inter-process communication mechanisms to achieve it.
It is important to keep an eye on all updates introduced with the newest versions of VS Code. In every release notes there is a section addressed to extension authors, describing the new APIs and capabilities available in the latest version. These notes often show us a more suitable implementation of an existing feature or give us an idea for a new one. Furthermore, by regularly checking the VS Code features voting portal we always know in advance what to expect from the upcoming versions. Usually, the top requested features are soon included in the official bits by the VS Code team.
Another valuable resource which helped us a lot along the way is the official VS Code repository. The issues section is full of valuable discussions, initiated mostly by community members.
The VS Code Insiders Build is another valuable tool in our arsenal. It lets us gain early access to the newest bits and test the NativeScript extension against them. This way, we are one step ahead of our users which gives us time to react to possible breaking changes, before the official version is released.
In the context of NativeScript, the Visual Studio Code extension is the little thing that makes the difference between a general purpose code editor and an IDE. Currently, the VS Code + NativeScript extension is de facto the standard tooling used by all our developers. The power of this combination is also confirmed by the VS Code Marketplace statistical data, showing a constant and exponential growth in the number of extension downloads. The feedback we are receiving from the NativeScript community also proves that by basing our tooling story on Visual Studio Code we are going in the right direction.
We’d appreciate if you gave it a spin (download VS Code extension for NativeScript) and you let us know what you thought about it at NativeScript Slack channel.
Well, I could have led with this paragraph to begin with. But I really wanted to first document our experience building an extension to VS Code. That said, if you made it through the blog post this far, you’d probably be interested what NativeScript is.