WSL 2 and VS Code
Tags: wsl, vscode, beginners, tutorial
Published: 2021-04-01 08:39:57

My [first post](https://dev.to/paddymorgan84/getting-started-with-wsl-2-ja) 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](https://code.visualstudio.com/) 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](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl).

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.

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vqyaen0fjfpexvphgqxm.png)
 
---

## 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:

```bash
> 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:

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kid9q5akja4ktxdbyeuv.png)

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:

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r6664h7pnbjorpfv45rg.png) 
 
This gives you the ability to browse your WSL distro in the same way you would a Windows filesystem to locate your project:

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/06w5ywl53e0vf11rs5pc.png)

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

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2fikju6ayg5deboh8tj4.png)

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:

```bash
> cd git/paddymorgan84/dotfiles
> code .
```

Or alternatively...

```bash
> 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:

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2o6plwbzbn4m8831fvxx.png)

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):

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xh0xmhfymiz1chyn8xew.png) 

- `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 :+1:

---

## 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](https://docs.microsoft.com/en-us/windows/wsl/compare-versions#performance-across-os-file-systems), 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](https://docs.github.com/en/github/getting-started-with-github/configuring-git-to-handle-line-endings), 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. :whale:

---

## References

- [Installing VS Code](https://code.visualstudio.com/download)
- [Getting started with VS Code & WSL](https://docs.microsoft.com/en-us/windows/wsl/tutorials/wsl-vscode#open-a-wsl-project-in-visual-studio-code)
- [VS Code & WSL tutorial](https://code.visualstudio.com/docs/remote/wsl-tutorial)

---

## Credit

[Remy_Loz](https://unsplash.com/@axellvak) for the photo :camera: