My Windows 10 Dev Setup
My new laptop arrived and I’ve to setup my dev environment for it. As the Windows 10 Creators Update is out and with that some new enhancements for the Windows Subsystem for Linux I decided to give it a try and go all-in with as much tools as possible in the WSL.
Establish a baseline for all kinds of programming environments, in my case it is .NET Core, Node.js and Go.
I researched of course a lot of existing material on the web and the one I decided to base upon is the write up from David Tran’s Windows Terminal Workflow Guide.
Have you ever wished that your Windows terminal emulator could look more aesthetically pleasing or be as feature rich…davidltran.com
With that post I first encountered the Hyper.js terminal from Zeit. It is a beautiful slick Electron based terminal wrapper which can be extended in various ways. It has also a plugin ecosystem which enables you to modify the behavior of the terminal or install new themes. So the stack to install is the following:
- Ubuntu on WSL
- oh-my-zsh replacing bash
- Hyper.js as terminal
- nvm with Node.js
- .NET Core
- gvm with Go
- Visual Studio Code
The Filesystem Thing
As we’ve both worlds the filesystem becomes an interesting point. It is important to know that the Windows filesystem is available through the mount point
/mnt in that case for the
C:\ drive it would be
/mnt/c like this
Dateisystem 1K-BlÃ¶cke Benutzt VerfÃ¼gbar Verw% EingehÃ¤ngt auf
rootfs 485977268 58813720 427163548 13% /
data 485977268 58813720 427163548 13% /data
cache 485977268 58813720 427163548 13% /cache
mnt 485977268 58813720 427163548 13% /mnt
none 485977268 58813720 427163548 13% /dev
none 485977268 58813720 427163548 13% /run
none 485977268 58813720 427163548 13% /run/lock
none 485977268 58813720 427163548 13% /run/shm
none 485977268 58813720 427163548 13% /run/user
C: 485977268 58813720 427163548 13% /mnt/c
root 485977268 58813720 427163548 13% /root
home 485977268 58813720 427163548 13% /home
First Things First
You’ll need Node.js on Windows to get Hyper.js with extensions up and running. Therefore I first installed that. I was installing WSL on the new laptop for the first time, but I also configured my work laptop the same way. WSL was already installed, but I decided to start from scratch.
lxrun /uninstall /full /y
lxrun /install /y
This command has to be executed in the Windows Command Shell. After that start Bash and upgrade Ubuntu
sudo apt update
sudo apt upgrade
Following the Guide
Basically I started following David’s Guide and executed all necessary steps. There are some additional steps I have taken.
Node Version Manager — nvm
I use nvm to install the Node.js runtime in WSL. This is done as documented. I’ll just had to modify
.zshrc myself as the install was modifying
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
With nvm in place installing Node.js is just specifying the version number needed.
nvm install 6.11.0
nvm use 6.11.0 --default
I’m going the Hybrid Way
There are at least two ways you can use WSL for you dev work. The purist way and the best of both worlds way.
The Purist’s Way
Basically you’ll never leave WSL. All your tools are in WSL land and there is no need to open up a Windows tool in your dev workflow. As there is no graphical subsystem (at least not per default) this would mean you’ll use all command line tools. Especially when it comes to editing files there is Vim and some nano, just go the Vim way in that case. I personally like Vim but my skills are too basic to be effective with that editor. But if you master it you have the best interop choice in my opinion as it is easily accessible through the command shell you can start it even up in an SSH session on a remote machine. Also consider using tmux in that setup.
The Hybrid Way
You want all the goodness from WSL but also your great tool support from Windows? This is the Hybrid Way or I also call it the Twice way. Why Twice? Because I want to use Visual Studio Code as editor. As this is a Windows application you’ll need to open your project files from the mounted Windows drives like
/mnt/c/work/src for instance. There you have to think where you want your
$HOMEto be. I'll keep mine still on the WSL
/home path, but you can also consider to use the Windows home directories for this.
When it comes to working with code I’ll use Node, Go and .NET Core in WSL land to compile and generate but Visual Studio Code needs the tooling to be installed the way that Windows can access it. Mostly for Intellisense or linting. Therefore I install also in parallel Node, Go and .NET Core on Windows directly. There is the burden of keeping those in sync. But hey, it’s fine for me.
No special quirks here, Just follow the basic guidelines for
Ubuntu 16.04 and you should be end up with that script
sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list'
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 417A0893
sudo apt-get update
// takes a while....
sudo apt-get install dotnet-dev-1.0.4
For the installation of Go I just followed the path of using version managers. There is also one for go: gvm.
Before I could use gvm I had to install the following dependencies
sudo apt-get install binutils bison gcc make
Before I can install any desired Go version beyond 1.4 I need to install 1.4 to bootstrap the compile process with an available Go compiler
gvm install go1.4 -B
gvm use go1.4
gvm install go1.8.3
gvm use go1.8.3 --default
The last steps are just fine tuning the settings for Visual Studio Code and I’m good to go. I should also mention that I’m using the
hyper-zenburn theme in Hyper.js. One thing I haven’t tried yet is to integrate a Docker workflow which would enhance the dev experience. As a convenience I created a Gist with all steps to have a look at. Here is the final result
Also there might be a better way to set this all up, please leave me a comment if you have some suggestions or corrections.
Scott Hanselman just did a great video on explaining how to edit and code with WSL in this video
Recent changes in Visual Studio Code enables debugging in the WSL directly
First steps towards WSL support
Thanks to a feature contributed by Bartosz Sosnowski (@bzoz), the Node.js debugger (for this milestone “legacy” protocol only), supports launching and debugging Node.js applications in the Windows Subsystem for Linux (WSL).
With this feature, you can add a
useWSL flag to a debug configuration to make it run in the Linux subsystem on Windows. The flag configures the debugger not only to launch the Node.js runtime in WSL but it also maps paths correctly between WSL and Windows.
Here is the simplest debug configuration for debugging
hello.js in WSL:
"name": "Launch in WSL",