Building a VSCode Extension: Part Two

Now that I have an idea of what I am going to build, It's time to set up the repository.

VSCode has a straightforward method for bootstrapping a new extension.

Making sure all the prerequisites are installed

The prerequisites for developing an extension is having Node.js and Git installed on your machine.

If you need to install Node, I recommend using NVM if you are on Linux or macOS and NVM-windows for windows.

Disclaimer: I develop on Linux, so I will be using those commands.

Install NVM using

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash

Restart your terminal then install node using

# Current LTS version while writing this is v12
nvm install 12
# I recommend setting this version as default
nvm alias default 12

Bootstrapping the extension repository

Now that node is installed to the latest LTS, it's time to bootstrap the extension repository.

Navigate to wherever you want to create the repository. For me, it's in a folder called workspace

cd ~/workspace

VSCode offers a Yeoman template to generate a basic extension.

Install the required NPM packages globally for Yeoman and the VS Code Extension template. After its installed, you can run the generator.

# Install the npm packages globally
npm install -g yo generator-code

# Running the generator
yo code

# ? What type of extension do you want to create? New Extension (TypeScript)
# ? What's the name of your extension?
### Press <Enter> to choose default for all options below ###

# ? What's the identifier of your extension?
# ? What's the description of your extension?
# ? Initialize a git repository? Yes
# ? Which package manager to use? yarn

I decided to use yarn because I normally use NPM but I wanted to try something new.

Since I am hosting the code on GitHub, I create a new empty repository there. Then I linked my GitHub repository with my local one.

cd vscode-todo-task-manager/
git remote add origin [e-mail]:CodeByCorey/vscode-todo-task-manager.git

git commit -am 'initialize extension'

git push -u origin master

Starting the development environment

Now that the repository is set up, time to run it locally.

# Since I am already in the project directory
code .
# the . means it will open the current directory in vscode

Once VSCode is open, press F5 to compile and run the extension.

To verify it is running, hit (ctrl+shift+p) and run the hello world command.

Time to dig into the API docs

Now that I have the base project running, I need to start reading the API Docs to figure out how to start implementing the task manager.

I might also look at some open-source extensions to see how they implement specific features. I tend to learn a lot from reading open-source projects.

Comments

[Michael Currin]

I can recommend using npx instead as it is builtin with Node and allows you to run yo without installing anything globally. The command is also much shorter.

github.com/MichaelCurrin/vsc-exten...

For first time installers of Node I wouldn't recommend NVM as you have to make sure its setup in your .bashrc or similar properly (it also adds a few tedious seconds to my terminal startup so I've abandoned it). And learning to use NVM is maybe more hassle than it's worth if one just needs to run npm or Node.

I added some easy install Node instructions here gist.github.com/MichaelCurrin/aa1f...

[Corey O'Donnell]

True, npx would probably be better than installing them globally.

I still find nvm easier to use for first time installers than installing it through a package manager. The install script automatically adds the setup to your .bashrc

Node should not be installed using sudo. You also cannot easily manage your node version. Based on your notes, you can see it installed 14. 14 is not a LTS version, so I do not recommend installing it through apt.

Brew is a bit different and does not install node with sudo and you can better manage which version you are using.

The startup time with nvm in a terminal is minimal.

edit:
Another side effect with apt would be the automatic updates. You could run apt update and install a new breaking version of node without realizing it. Now your local scripts might not work.

[Michael Currin]

Thanks for the response. I've added NVM as an option in my Node gist and also added how to get the LTS version which is 10 or 12 depending on distro (it is 10 on my Linux Lite machine).

On Debian/Ubuntu, using sudo is a natural part of apt for curl, python3, libs etc. I don't use sudo for installing Node packages but for Node itself I think it is fine. Debian community is focused on security and stability so that's why they won't be using the latest.

On my work Mac I commented out the NVM activation lines in my rc file and it took my terminal setup time from seconds to near instant. I never had the issue before the mac upgrade that I can remember so maybe it's a Catalina or ZSH thing.

Yes you're right about the auto update with apt is a risk. But that is acceptable to me. I get the latest security updates with apt and any breaking bugs should be fixed quickly. I think breaking syntax is unlikely since JavaScript syntax is backwards compatible to not break things on Node and the browser.
If you use some bleeding edge modern syntax then yes it is going maybe change.

[Michael Currin]

Also you can lock an apt package version. Today I learned!

askubuntu.com/questions/18654/how-...

[Corey O'Donnell]

I never really noticed that load time for NVM. The half a second it would take on my machine didn't bother me but I decided to look into it.

When you source nvm, you can add --no-use to it.
no-use documentation
This will then prevent nvm from sourcing node until you run nvm use.
This should pretty much source the nvm script instantly now.

[Michael Currin]

Thanks for sharing.

Works for me.

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" --no-use
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"