WSL 2 and VS Code

My first post in the series focussed primarily on installing WSL 2 and getting familiar with some of its standard features and commands. Hopefully, at this point, you'll have a fully functioning distro running on your machine. If not, have a read back and get yourself up and running.

With the second post, I want to focus more on how you can start to make use of WSL 2 as part of your day to day engineering life.

Working with VS Code

I primarily use VS Code as my IDE. It's open-source, lightweight & clean, has a very active community with regular updates, and it has a vast array of extensions available to you, one of which is the Remote WSL extension.

While your IDE remains on Windows, all your commands, extensions, files, and terminal are running on your WSL instance. Once you've installed the extension you'll see a little icon at the bottom left of VS Code.

Opening a project

To better show this, I'm going to clone one of my repos into WSL. When I clone git repos, I like to have a git folder in the $HOME directory, followed by the organisation or user within that. So for example, on a fresh WSL distro install, I would do this:

> cd ~ 
> mkdir -p git/paddymorgan84
> cd git/paddymorgan84
> git clone https://github.com/paddymorgan84/dotfiles.git

Sidenote: The -p flag we're using for mkdir indicates that if the parent directory doesn't exist (which in this case, it definitely won't) rather than error it will create that directory as well, concatenating your mkdir command into a single call.

There's a couple of ways you can open a project:

Option 1: From VS Code. You can use ctrl + shift + p to open up your command palette, then search for WSL, which will provide you with a multitude of WSL related options. Clicking on the new icon in the bottom left of VS Code will also present you with the same options:

Select Remote-WSL: Open folder in WSL... and it will open up Windows Explorer and point you to a network drive that's been created on your machine to support WSL:

This gives you the ability to browse your WSL distro in the same way you would a Windows filesystem to locate your project:

Once you've selected your folder, VS Code will open up your project:

Two things to take note of here. The first is that the bottom left of your IDE will indicate you're now using a remote WSL connection to your Ubuntu-18.04 distro. The second is that your integrated terminal (ctrl + ' if you don't see this) is also using your distro, and will have automatically opened to the location of your project on your WSL filesystem. This gives you a clean, immersive experience of developing within Linux.

Option 2: From WSL. If you want to work directly from the terminal (as I tend to do) then you can call the code command from your distro, which will open a VS Code instance on your Windows machine with whatever folder you've run the code command for. For example:

> cd git/paddymorgan84/dotfiles
> code .

Or alternatively...

> code ~/git/paddymorgan84/dotfiles

Personally, I'm a big fan of using the terminal and I try to operate out of there as much as possible. I feel it's more efficient and makes me more productive as an engineer, and it also means I can add cool little aliases that can open my common projects up with a few keystrokes:

I'll be discussing aliases later in the series.

Installing extensions

Using the Remote WSL extension means that instead of having a totally native experience, what you actually have is a "client-server" architecture; VS Code (the UI, at least) is running on Windows, but the server (everything else under the hood) is running remotely on WSL.

As a result, a lot of your extensions will need to be re-installed on your distro (and any subsequent distro) for you to have them available.

Fortunately, VS Code makes this really easy. Assuming you have a WSL remote project open, press ctrl + shift + x to present you with the Extensions pane. You'll notice a few subtle differences from a standard Windows VS Code experience (I've highlighted the important bits):

• Local - Installed tells you what extensions you have installed when running VS Code with a Windows-based project.
• WSL:Ubuntu-18.04 - Installed tells you what extensions you have installed on your distro.
• Install in WSL:Ubuntu-18.04 does what it says on the tin.

The thing I want to emphasise about this is that getting all the extensions you love to use on Windows can be installed onto your distro in a matter of seconds 👍

Don't halfway-house the filesystem

When I first started dabbling with WSL, I rather confusingly decided to keep my files located on my Windows drive, then use the mount points WSL provide (/mnt/c/, for example) to locate those files and operate from WSL.

As I write this now, I struggle to remember why I did this other than the fact it wasn't quite as big a leap away from Windows and there was less up-front work to get started.

I would wholeheartedly recommend you don't do this. Firstly, Microsoft themselves try to warn you against this, primarily because the performance isn't great.

Secondly, I found that I would have annoying inconsistencies that meant I had to modify my configuration to work around it. For example, I often found myself battling with line endings in my GitHub repos, something that differs between Windows and Linux. Git has ways and means to help solve this, but ultimately I migrated all of my projects to my distro and my experience improved drastically.

My advice would be to just take the leap.

That's a wrap

Part 2 of my series is done and dusted, I really hope that you've found it useful. Next up I'll be talking about using WSL 2 with Docker. 🐳

References

• Installing VS Code
• Getting started with VS Code & WSL
• VS Code & WSL tutorial

Credit

Remy_Loz for the photo 📷