Nick Janetakis

Posted on Jan 2, 2019 • Originally published at nickjanetakis.com

A Linux Dev Environment on Windows with WSL, Docker, tmux and VSCode

#docker #productivity #windows #vscode

This article was originally posted on December 21st 2018 at: https://nickjanetakis.com/blog/a-linux-dev-environment-on-windows-with-wsl-docker-tmux-and-vscode

Over the last 5+ years I've tried all sorts of setups. Everything ranging from
dual booting Linux to using aVMware based Linux VM and now I'm happily using WSL.

I wrote about using WSL over a year ago and I've been using it ever since. Over the last year, I've evolved my development environment and the video below is the latest iteration.

The last video I recorded of my dev environment was nearly 3 years ago, so I was long overdue for making a new video. Enjoy!

Demo Video Showing Everything

Timestamped Table of Contents

1:08 -- Why use Windows?
1:44 -- Terminal set up (Ubuntu 18.04 WSL / tmux)
4:09 -- Dealing with Windows updates and restoring terminal sessions
5:38 -- The tools I use blog post
6:22 -- Virtual desktops
7:28 -- Reverse searching your terminal history
7:47 -- Dotfiles link on GitHub
7:57 -- Visual Studio Code
9:26 -- Splitting and resizing windows
10:13 -- Modifying a web app workflow
13:19 -- Multiple clipboards with Ditto
14:37 -- Searching and launching apps with Keypirinha
15:19 -- Browser and screen sharing tools
16:47 -- Chatting on IRC with HexChat
17:26 -- Managing passwords on the command line with pass
17:55 -- Finance tracking with GnuCash
18:26 -- Various hardware I use
18:58 -- Recap of everything

Reference Links to Install and Configure Everything

Final Thoughts

It's nothing but smiles all the way down. I've never been this happy and more productive before when it comes to my development environment.

I'm super thankful Microsoft has stepped up their game. I'm excited for the future.

What do you think? Am I missing anything interesting? Let me know below.

Top comments (24)

Adrian B.G. • Jan 3 '19

Over the last 6 years I professionally develop using:

Linux
Windows
MacOS
WSL
Linux in a VM (local and on AWS with VNC)
C9 IDE

I can say that WSL is not ready for professional use and all developer technologies will be limited on Windows because the lack of adoption.

Everything else than Linux and maybe Mac are just a shadow, trying to mimic a Linux env, and this choice will byte your as* in the future, and you will spend many days trying to fix a dependency, a missing feature, an issue that the library developers will not fix because they do not use Windows/WSL.

Just my 1 cent.

Nick Janetakis • Jan 3 '19 • Edited

I suppose it depends on what you're working with.

For me WSL has been fantastic for developing web apps with the following tools:

Rails, Flask, Django, Node, Phoenix, Jekyll and Webpack.

Everything is fast, and the development loop isn't riddled with weird bugs or edge cases. I didn't come across any issues.

Besides those apps things like SSH, GPG keys and various other Linux tools are working great.

Vignesh D • Jan 3 '19

How about node? Is it really fast? Few months ago,when I tried WSL, npm install in a fresh laravel scaffolding took atleast 10 minutes. Disk performance was very very poor.
Since then, I left WSL. Is it really fast? When comparted to dual booted Linux?

Nick Janetakis • Jan 3 '19 • Edited

Node is listed there as well as Webpack.

I use Webpack in nearly all of my web apps and in a typical Webpack set up using ES6 JS + PostCSS + SCSS + Bootstrap + Font Awesome 5 + custom SCSS, it's really fast. Webpack takes around 500-600ms to pickup the changes if I make a SCSS change and JS is even less time.

It updates faster than I can move my cursor to my browser and hit CTRL + R to reload.

Laravel is another story. The initial composer install takes a while, a lot longer than Rails or any of the other set ups, but... once everything is installed, the disk performance is fine. If I make a change to an asset, it picks it up in less than 1 second and code changes to the Laravel app itself is nearly instant.

But to be fair, I don't work with Laravel on a regular basis. 99% of my client work is one of the tools listed in my other reply. It just so happens I was working with a Laravel app yesterday tho, so this is still fresh in my mind.

Dual booting isn't an option for me. I used to do it, and it's a horrible context switch, even if it only takes a minute with an SSD. It's the fact that you lose everything between each dual boot.

Plus for me, it's not an option because I need to be able to record my development environment with video editing tools and nothing exists on Linux that's usable IMO.

Vignesh D • Jan 3 '19 • Edited

Convincing enough about performance.
How about tooling support ? VSCode can provide linting via eslint and tslint packages. It can provide Autocomplete for Php using PHP interpreter. For such functionalities, VSCode requires PHP Interpreter. In case of WSL, everything lies in side it. VSCode installed to windows can't access the linux tooling inside WSL?

Nick Janetakis • Jan 3 '19 • Edited

You have a few choices with tooling support.

For example I have VSCode running on Windows, but I have the shellcheck (Bash) linter installed directly in WSL and it works great because shellcheck has an option to make it work in WSL, so it really comes down to what tools you use.

But, if you want a sure fire way to get full support for everything, you can go down the route of installing VSCode directly inside of WSL instead of Windows.

That is mentioned in one of the blog posts I linked at nickjanetakis.com/blog/using-wsl-a.... Do a search for "Setting Up MobaXterm to Run Graphical Linux Apps".

Ariel Alvarez • May 1 '19

WSL supports interoperability. I'm using it successfully with Sublimetext Sublimelinter and Vscode linters. Just check it out docs.microsoft.com/en-us/windows/w...

Adrian B.G. • Jan 3 '19

All my issues were with Node and packages dependencies.

I would not call anything Windows related fast.

Nick Janetakis • Jan 3 '19

Maybe it was an older version of WSL that you were using. Yarn install is pretty speedy for me with Windows 18.09's WSL.

You might want to try disabling Windows Defender for WSL or even all together. I know a lot of people said WSL was slow for them when you run that tool. It was one of the first things I disabled after installing Windows before I even used WSL.

Sebastián Duque G • Jan 2 '19

Nice video! Does the

$ code .

integration with Windows vscode ships out of the box?

Sebastián Duque G • Jan 4 '19

Hey @nickjj , it's me again.

I've been playing around with WSL and I'm very impressed about the work done there. Talking about these integration between with the Windows host and the VSCode integration, I know there are some binaries as jdk's "java" binary which can be shared from the windows installation to WSL which I find very interesting because I can use java dependent windows programs and use command line tools (mvn, openapi-tools... etc) using the same jdk installation.

In the case of node & npm, do you recommend having a single shared installation or to installit in both Windows & WSL? The idea of having it avaialble in Windows is to have the option to run node dependent apps like Hyper or NativeScript Sidekick.

Nick Janetakis • Jan 4 '19 • Edited

Hi,

I personally don't have Node installed on Windows, but it's up to you. I got rid of Hyper a while back because it was horrendously slow compared to other terminals. That adventure was documented at nickjanetakis.com/blog/conemu-vs-h....

But, I'm not here to rain on any parades. If you have some Node apps on Windows that benefit from having Node natively installed on Windows, then go for it.

Although with that said, I have VSCode installed on Windows but I didn't specifically install Node. I let VSCode manage its own installation.

Sebastián Duque G • Jan 4 '19 • Edited

I have dived into this setup and found an interesting behavior (a problem actually). Just opened a stackoverflow question to see if someone has done a similar setup. I have found a solution (workaround as of now, want to have other's opinion) but I'm posting it later, need some sleep.

Nick Janetakis • Jan 4 '19

I've never done anything like that but in your symlinks you have node.exe in the Windows path but then you put npm and npx. Shouldn't those also end with .exe?

Nick Janetakis • Jan 2 '19 • Edited

Yep. I didn't add anything special.

I only added an alias for alias code="code-insiders" because I use Code Insiders but prefer typing code instead of code-insiders.

All of my Bash aliases and everything else (including VSCode config) is at github.com/nickjj/dotfiles.

Sebastián Duque G • Jan 2 '19

Great! Another thing I would to know is.. How did you set your desktop theme (taskbar, apps toolbar... etc) to that nice looking blue? I have been in Linux for a while so I'm not aware of Windows customization... Perhaps I'm switching to a setup similar than yours :)

Nick Janetakis • Jan 2 '19 • Edited

The theme colors are standard Windows 10 features.

Right click your desktop
Choose the Personalize menu item
For colors, goto the Colors tab on the left
Uncheck automatically pick accent color
Pick a custom color, mine is specifically #03357B (the color selector lets you input hex values if you hit More)
Uncheck transparency effects
Check both accent color options (start, taskbar + title bars and windows)
Use light as the default app mode

Now your taskbar, start menu and all of your windows will use that custom color.
If you're happy with your set up, you can goto the Themes tab on the left and then save it as a pre-set.

I also modified VSCode's workbench colors so it matches my Windows theme. Those settings are in my dotfiles.

David J Eddy • Jan 2 '19

Hello Nick. Nice setup. I use a similar setup @ work these days as well. WSL indeed has come a long way in the past couple of years. For video editing are you using Adobe Creative Cloud? I ask 'cause CC + OSX might be an alternative if you find yourself running up against the limitations of WSL.

Either way, nice video. I look forward to the next one.

Nick Janetakis • Jan 2 '19 • Edited

I use Camtasia for video recording and editing, or OBS for streaming.

I don't want to switch to MacOS because IMO there's better gaming support with Windows and I like the idea of having 1 computer that I use for both work and gaming.

There's other neat bonuses of WSL too for development over MacOS, such as having a "real'ish" Linux environment. I deploy all of my apps onto Ubuntu 18.04 using Ansible, and that means I can reuse a lot of things to set up my WSL environment since I also run Ubuntu 18.04 in WSL.

I've gotten things set up now where I can run 1 Ansible command and everything about my WSL set up gets automatically configured and it only took about 10 lines of YAML since I was able to reuse everything I use for my production environment in terms of Ansible code.

Kirill V • Jan 4 '19

Could you go more in-depth on integrating Docker into the workflow? From what I understand, from looking at other tutorials, you need a 'volumes' section in the docker-compose file that looks at your code, with separate folders that aren't watched for dependencies, such as node-modules, venv if you're using that, etc?

Nick Janetakis • Jan 4 '19 • Edited

For development I almost always volume mount .:/app which would mount in the current directory (the source code) into the /app path in the container which is a general place I use to keep my source code in the container, but in your case the /app part might vary.

I don't worry about node_modules/ because at Docker build time I configure yarn to install its dependencies into /node_modules inside the Docker image instead of node_modules/ which is relative to /app.

You can do that with a .yarnrc file by putting in --modules-folder /node_modules.

In other words, I don't end up with 42 billion node dependencies on my dev box through the volume because they're never mounted.

The same strategy applies with other language package managers that install dependencies to relative folders by default (such as Composer with PHP and Mix with Elixir).