Creating a VS Code Extension Part 1: Setting up a development environment

Choosing a language, using Yo Code, and getting set up for development

Haris Khan

8 minute read


This is the first of a multi-part series on writing a VS Code extension! If you don’t want to write a VS Code extension, that’s ok! We’ll cover other material that is generally applicable to software engineering projects. Feel free to skim.

I will be talking about AWS in this series, but no background knowledge is required. This is strictly a series on building a VS Code extension.

I have a pet project that I’m working on: a serverless blog (go figure) web app that is super lightweight can be deployed quickly, easily and hosted very cheaply on AWS. The blog data will be stored in a NoSQL database that AWS offers called DynamoDb. However, while developing the schema for this database in VS Code (which has quickly become my go-to code editor, replacing sublime), I had to constantly use the terminal to run commands, tests, etc. There was no extension for DynamoDb in the same way there was for MongoDb. I looked into getting a viewer but AWS doesn’t offer anything and there were no free options. I wasn’t about to shell out 100 bucks for a pet project, especially since it would totally defeat point of the project being a ultra-low cost option.

Since I really wanted a viewer, and it didn’t seem like anyone was building a VS Code extension to do it, I decided to give it a crack myself!

Please note that we will not be covering how to build a Language or Debugger plugin, as those have additional complexities that would take entire series’ of their own to cover. We’ll be skipping those parts of the API which deal exclusively with these extension types. We’re also skipping themes and extensions that purely alter the visual experience of VS Code. I think themes are really cool, but I don’t really have the design expertise to build one myself, let alone teach someone else how.

Some Definitions

Here are some important definitions to store in your brain somewhere before we get started.


Amazon Web Services, which is Amazon’s cloud computing subsidiary. We will be focusing specifically on their DynamoDb product.


AWS’s NoSQL Database offering. Kind of like MongoDb in many respects, except it’s closed-source and operates on the cloud. You can download a local version to develop with.


A strict superset of JavaScript that transpiles to ES5. If you don’t know what that means, read this.


Node.js Package Manager. It is distributed with Node.js, and is a requirement to get our development environment up and running.

Extension Manifest

What VS Code calls package.json. It actually performs a few other functions than a simple package.json file would, so we will refer to it (most of the time) as the Extension Manifest in this series.


Visual Studio Code Extension manager. Command line tool that we’ll use to publish our extension to the marketplace.

Setting up our development environment

With those definitions out of the way, lets get coding!

Well, not quite yet. There’s a few prerequisites we have to meet before we can actually install an extension. The first is that you’ll need a Microsoft account. VS Code is maintained by Microsoft, and leverages the Visual Studio Team Services marketplace to manage it’s plugins. You’ll need to create a VSTS account, or connect an existing Microsoft account if you don’t already have one. Setting it up is easy if you follow the link above.

Once you’ve set up your account you should have a homepage like Navigate to it and follow these instructions to set up a personal access token. I recommend setting the expiration for 1 year. Once you have the token store it somewhere safe, because you will not be able to retrieve it again!

Installing and configuring vsce

In order to be able to publish and work with VS Code extensions, we’ll need to install vsce and set up a Publisher. This is why we needed the access token.

If you don’t have Node.js installed, you’ll have to do it now. Go here to download the latest version.

Use the following command to set up vsce:

npm install -g vsce

If this fails telling you to “Please try running this command again as root/Administrator”, prefix the command with sudo and input your local user password.

his will install the vsce globally, along with all it’s dependencies. You’ll be able to run vsce commands from any terminal in any subfolder.

The next step is to set up a Publisher. The Publisher is what identifies your plugins on the Visual Studio Marketplace.

vsce create-publisher (publisher name)

It’ll prompt you for a human-friendly name (you can use spaces and special characters e.g., an email address, and the personal access token that you generated earlier.

Using the Yo Code Extension Generator

In order to get started with any plugin, generally speaking the software maker will provide you with documentation detailing the required prerequisites and file structure to work with the program. In our case, Microsoft has done us one better: they gave us a npm package that will generate the bones of the project for us!

Let’s install the extension generator. Open up your favorite flavor of terminal and input this command:

npm install -g yo generator-code

When you’re ready, navigate to the directory where you want the project to live, and run the following command:

yo code

You’ll should see a cool frood asking you to make some decisions. The first decision you have to make is whether you’re going to use pure JavaScript or use TypeScript instead.

Let me make this decision for you: TypeScript. You’re welcome.

What do you mean why? Didn’t you read the definition?

OK, let me elaborate. TypeScript is a strict superset of JavaScript, meaning that it is JavaScript, plus some other stuff. You can write pure JavaScript in a TypeScript file (.ts) and it will work in a browser. The TypeScript transpiler at that point is basically acting like Babel. So if you pick pure JS, you’re stuck with it, whereas if you pick TS, you can write either.

There are other reasons why I think TypeScript is superior, but really, that’s enough of a reason to choose it here considering the two options available to you. If you want to use pure JS, go ahead. If you want to use TypeScript later, or partially, the option is open to you.

The rest of the installer is pretty straightforward: give the extension a name, an identifier (in the format vscode-extensionname), a one-line description, your vsce Publisher name, and tell it whether or not you want to initialize a git repository. Once your done, hit enter and it’ll generate the boilerplate and install the npm packages for you (I kinda wish it didn’t, but we’ll get to that in a second).

Open the newly created folder in VS Code.

Fixing the dependencies

You might see a few warning messages (this might be fixed by the time this is published, I don’t know) about deprecated packages when . Some of these are pretty nasty:

npm WARN deprecated jade@0.26.3: Jade has been renamed to pug, please install the latest version of pug instead of jade
npm WARN deprecated to-iso-string@0.0.2: to-iso-string has been deprecated, use @segment/to-iso-string instead.
npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue

Let’s do a little updating. Open up your package.json file and scroll down to the DevDependencies section. If you hover over some of these, VS Code will actually show you what the latest version is! Neato!

"devDependencies": {
        "typescript": "^2.0.3",
        "vscode": "^1.0.0",
        "mocha": "^2.3.3",
        "@types/node": "^6.0.40",
        "@types/mocha": "^2.2.32"

…let’s update some these.

"devDependencies": {
        "typescript": "^2.0.3",
        "vscode": "^1.0.0",
        "mocha": "^3.5.3",
        "@types/node": "^8.0.20",
        "@types/mocha": "^2.2.32"

Hit alt-tilde to open up the terminal and run an npm install to update the packages accordingly. When we do, no more warning messages! Awesome!

Note: The ^ in front of each of the dependency versions tells npm to update the package to the latest non-major version (i.e. 2.0.3 doesn’t need to be changed in the package.json because it will still to the latest version, which happens to be 2.4.2, automatically). It will not upgrade for a major version release of a package however (2.x.x to 3.x.x), as those can have breaking changes. If you’d like to change this so you can control package updates more incrementally, go ahead and remove the ^. You can read more about package.json here.

OK, let’s give this thing a run! The boilerplate is a classic hello-world example. Hit F5 to try it out. A new window VS Code window should open! Your original window is now in debug mode, so you should see debug messages appear there. Open the command palette with ctrl-shift-p or cmd-shift-p, and start typing “Hello World”. You should see in in the auto-complete; select it and hit enter.

Hello World

Look at that! It works!

Alright, we’re all set up and ready to go. In the next post we’ll start looking at the file structure of the extension and talk about how VS Code deals with extensions generally, in the context of the sample code.

comments powered by Disqus