Developing on Windows, the WSL life

The Windows developer experience has evolved quite allot in the last 5-10 years. I now spend most of my development life running Windows with WSL2 and using Windows Terminal and winget. So here are a few pointers from my experiences so far.

WSL (WSL2)

WSL2 is what you want! The first version of WSL was a step in a great direction, but had many cons, such as IO performance. It should be fairly easy to install and will provide you a full Linux Kernel accessible from within Windows.

WSL also has access to your Windows filesystem via a mount at /mnt/c. Generally if you are using Linux tooling, you’ll want your file access to remain in the Linux file system. For example, I have almost all of my git repositories checked out in my Linux file system. For the odd repository that I use mainly Windows tooling I leave in Windows land.

Packages

I use apt for Linux land and winget for Windows land. You can start to see the Windows ecosystem imitating some of the best parts of the loved Linux experience. For example, to install git in Linux, you have apt install git. And to install git in Windows you can now do winget install git.

Generally speaking packages installed on each side of the Windows / Linux line are only accessible from that side. And you probably only want to access the binaries for the appropriate side. Though you can always run the Windows binaries from a Linux shell by specifying git.exe for example. On the odd occasion it’s helpful to do something like explorer.exe . on the Linux side, to get a Windows experience.

Windows Terminal

There are many ways to install Windows Terminal. You’ll note one of the README suggestions is winget.

winget install --id=Microsoft.WindowsTerminal -e

This will give you easy command line access to both your installed Linux distro, and Windows Command Prompt / Powershell if you ever need it.

Docker

Docker for Windows, which is installable with winget install docker will run Linux containers on WSL2 behind the scenes. Although WSL2 still uses virtualization under the surface, its much faster than any virtualization from things such as Docker Toolbox etc.

When installed the docker CLI will give you and option to be available in select Linux distros. You should choose this option for your distro to have a mostly seamless experience.

SSH

I use KeePassXC in Windows land, that has the ability to load ssh keys into an SSH agent. One of the easy checkbox options is now called Use OpenSSH for Windows instead of Pageant, which you will want to enable.

With a small bit of “magic” I copied from a README on github you can fairly easily pipe the built in Windows SSH agent through to Linux. In my .bashrc it looks somehthing like this:

export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock export WINHOME=/mnt/c/Users/adam ss -a | grep -q $SSH_AUTH_SOCK if [ $? -ne 0 ]; then rm -f $SSH_AUTH_SOCK ( setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"$WINHOME/bin/npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork & ) >/dev/null 2>&1 fi
Code language: JavaScript (javascript)

Note, I also had to download npiperelay.exe. which I saved to %USERPROFILE%/bin/npiperelay.exe, on the Windows side.

IDEs

Personally I use VSCode with its included WSL remote support. This provides a seamless experiences between both Windows and Linux file systems.

Every now and again I do still want to use one of the many JetBrains IDEs. For these cases I’ll install the IDE in the appropriate side, Linux or Windows, and run it there. Here you can make use of GUI support for Linux apps (If you are running any version of Windows 11 Build 22000 or higher).

Disclaimer

This post should act as a good overview of Windows development using WSL2.

It’s been quite some time since I set up some parts of this, such as the SSH Agent tunnel, so it could be slightly wrong.

Generally speaking I love this setup, and am happy to answer any questions on it etc.

Feel free to reach out to me in the comments, on Twitter or elsewhere.

4 responses to “Developing on Windows, the WSL life”

  1. Thanks so much for this helpful page! I’m running WSL and using it in some of the ways that you mentioned above. This page was helpful to me in getting started. I am still on Windows 10. Most of my work involves (JavaScript / Node) software development where the source code lives and runs in WSL, but I use IntelliJ Ultimate running in Windows.

    I have one big pain point: When I run a suite of mocha tests in IntelliJ, I have to wait around 5 minutes for the preparatory steps (the steps where IntelliJ displays “Instantiating tests”). Very interested to know if you have encountered this problem or know anything about it.

    I assume this might have something to do with communications between Windows and WSL processes. So I’m interested to know if you think the problem would go away if I upgrade to Windows 11 and install IntelliJ in WSL

    Note: I’m already aware of the guidance here (but it hasn’t led to a solution): https://www.jetbrains.com/help/idea/how-to-use-wsl-development-environment-in-product.html

    Thanks!

    • In a nutshell the issue is that Windows applications talk to code in WSL / Linux land via something that is effectively a network mount.
      You can read more at https://docs.microsoft.com/en-us/windows/wsl/filesystems#file-storage-and-performance-across-file-systems

      This is actually one of the reasons that I switched from IntelliJ to VSCode.
      VSCode runs a client on Windows land and the actual IDE code / server in WSL land (Remote mode).
      It’s pretty seamless and as speedy as you would want, there is a diagram at the bottom of this post that has some arrows showing what I mean.

      Looking at those InteliJ docs it does look like you should be able to get comparable speed with configured run targets, but it doesn’t come out of the box.
      I hope that https://www.jetbrains.com/fleet/ when released might improve this situation and I might jump back.
      The key part there is “Remote machine: Connect to a remote machine and use an instance of Fleet running there to work with your code.”
      WSL in this case is like a virtual machine.

      If you are running WSL with graphics support you can also install your IDE in WSL land and run the linux version.
      the UI might look a bit weird and jankey but it would make things faster in terms of running your tests.

      • Thanks so much for the extremely helpful reply! I think my next step will be upgrading to Windows 11 and installing IntelliJ in WSL land. One quick follow-up – with the WSL support for running Linux GUI applications (available with Windows 11), would you still expect the UI to “look a bit weird and jankey”?

        • So generally speaking the UIs work fine.
          The main thing is that the scales will be off a little in comparison to windows land applications, but perfectly useable.
          Resizing can sometimes be a little slugish etc
          Here is a visual example…
          Screenshot of Firefox displaying Wikipedia in Windows vs WSL

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: