Integrating your dev workflow with WSL

Windows Subsystem for Linux, or WSL for short, is a quite impressive piece of technology, and one of the best moves Microsoft could have made to attract developers. Particularly web developers.

Basically, WSL allows you to open up a Terminal (which by the way got totally modernized), open up a new Linux tab, and just be greeted with good ol’ Bash, running in a real Linux kernel instance.

Before WSL, to work on a Rails or PHP application, you really just had to use an UNIX OS, be it macOS or Linux. On UNIX, everything just works. The language developers use UNIX, the ecosystem is made for UNIX, there are package managers, setting everything up is a breeze. On Windows, you struggle at each step.

Until now. With WSL, you can get the best of both worlds! Microsoft provides you with a modern Terminal, as well as a one-click install for the most popular Linux distributions out there, using the Windows Store. It’s even easier than installing Linux manually.

Within minutes you can be up and running in a new Linux instance. What’s nice is that you can have many different instances running together, if you ever need to. You can have Ubuntu on one tab, and openSUSE Leap on another.

It feels pretty magical, using a text editor on Windows which uses a Linux binary to lint files on-the-fly.

Another nice thing about WSL is that it just knows about your Windows filesystem. So you can use Bash to navigate to your C:\Users\MyUser folder and, for example, create a Rails app there. And you can navigate to it using Explorer, just like you normally would. Running explorer.exe . will work as expected.

Because of this nice integration, you can use any Text Editor on the Windows side to write code which gets later executed in your Linux environment.

Integrating WSL with (neo)Vim

This is all nice and dandy, but how can you make your editor play nice with WSL? Many extensions require us to have some things installed, like ESLint or Rubocop.

Luckly for us, WSL provides the wsl command. For example, we can run wsl /usr/bin/tree to execute the tree binary on the Linux side from the Windows side.

Knowing this, we can configure our editor to use this executable instead. It does has it downsides, as it surely is slower, but the convenience is just too good to let it pass, in my opinion.

I personally use Neovim for developing, but the following steps apply for any editor, or application which needs to talk to external executables.

WSL with Neovim, ALE and Rubocop

ALE (Async Lint Engine) is a plugin for both Vim and Neovim which supports many different linters. Among them is Rubocop, by checking for the rubocop binary.

Normally, it would just work out of the box if you have in installed, but when running on Windows with WSL, we need to make a few adjustments.

First of all, I’ll create a new directory to store many useful binaries, some from WSL, others native. I normally do this in D:\bin and add it to my PATH environmental variable.

In this case, I create a new file D:\bin\rubocop.cmd:

As you might have noticed, I take an extra step and translate Windows’ forward slashes to UNIX backward slashes so nothing breaks on the Rubocop side. This is not needed for all applications, but it is needed for Rubocop in this case.

And that’s it! Now Neovim knows where to find an executable named rubocop. It feels pretty magical, using a text editor on Windows which uses a Linux binary to lint files on-the-fly. And I can manage the Linux side just as I normally would.

WSL 2 and beyond

This is just the tip of the iceberg, WSL 2 now supports GPU acceleration, and eventually you’ll be able to run Linux GUI applications as well! You can even use docker if you want.

WSL is still quite new at the moment, so it does have a few rough edges here and there. But the future look promising, and you can already do some pretty awesome things with it.

Hope this helps you out a bit if you do decide to give this WSL thing a shot.


— Fede

Leave a Reply