With the release of the Creators update, WSL now has proper networking, 60%+ better support for Linux system calls, and the best feature of all: the ability to execute Windows native executables. You can read more about this here.

Here’s a couple tips on settings this up for web development, including Trellis.

mintty

First of all, I recommend using mintty as a terminal. You can install it using the instructions on the wsltty repo.

You can check out various other terminals such as cmder and Hyper which both support tabs, but for now, wsltty provides a nice drop-in replacement to the default.

zsh

Most people prefer zsh over bash . If you’re interested, let’s set that up real quick before we get started.

sudo apt-get install zsh

While there are alternatives, I’ve never had any issues with oh-my-zsh and the plugin support is great. Let’s grab that real quick too…

sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

While normally we’d be able to simply use chsh zsh to change our shell to zsh, /etc/passwd appears to be ignored at the moment for the default shell and I’m sure will be addressed in the future.

For now, we will add the following lines to ~/.bashrc to exec zsh on start:

nano ~/.bashrc

# Launch Zsh if [ -t 1 ]; then exec zsh fi

Once we do that, restart Bash and we should be on our way. After setting up the below, make sure to check out the massive amount of Plugins and Themes for oh-my-zsh.

PHP

An important part of keeping your workflow native and sane is getting a proper installation of PHP 7.1 running locally to allow usage of wp-cli and Composer.

Let’s set that up.

PHP 7.1

sudo add-apt-repository ppa:ondrej/php sudo apt-get update sudo apt-get install php7.1 php7.1-mbstring php7.1-xml

Composer

curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/local/bin --filename=composer

wp-cli

cd ~ && curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar chmod +x wp-cli.phar sudo mv wp-cli.phar /usr/local/bin/wp

Node.js

The next step will be a proper installation of node.js and yarn. We will do this using nvm .

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.1/install.sh | bash

After installing nvm , you will need to source it in your ~/.bashrc or ~/.zshrc .

if [ -r ~/.nvm ]; then export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" fi

After doing that, if it’s setup properly, we should get a version response from nvm.

Great.

Let’s go ahead and install the latest version of node and set it as our default version.

nvm install node nvm use node nvm alias default node

Now we can go ahead install yarn globally.

npm install --global yarn

rbenv

This can sometimes be preference vs using rvm, but I opted for rbenv due to the reasons listed here as well as it working as I need it too without any overhead.

To prepare for building Ruby, let’s start with a couple packages to make our life easier.

sudo apt-get install build-essential gcc zlib1g-dev zip

Now let’s get rbenv cloned to our home directory along with the ruby-build plugin:

git clone https://github.com/rbenv/rbenv.git ~/.rbenv git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

and at this point, we should be able to compile rbenv’s dynamic bash extension to speed things up a bit:

cd ~/.rbenv && src/configure && make -C src

Like we did with nvm , we need to source rbenv in our ~/.bashrc or ~/.zshrc file.

if [ -r ~/.rbenv/bin ]; then export PATH=$HOME/.rbenv/bin:$PATH eval "$(rbenv init -)" fi

Ruby

Now that we have rbenv installed, we can install Ruby.

At the point of writing this, 2.3.3 is the latest so lets go with that.

rbenv install 2.2.3

This can sometimes take a few. If it errors out complaining about dependencies, it usually has a convenient apt-get that you can copy and paste to grab them.

Once it is installed, let’s set it as our default version globally.

rbenv global 2.3.3

and we should be set. Let’s check ruby -v just to make sure.

Looks good.

Vagrant

As much as I’d love for it to be, using the Ubuntu package for Vagrant is just not sane yet. While there are numerous, albeit tedious ways to get it working, it is still no where near as functional as the native Windows version and to avoid the issue all together, we’re going to simply make an alias so vagrant actually points to vagrant.exe which if you added Vagrant to your PATH during installation like you should have, will work quite well.

Symlinks

Also added in the Windows 10 Creators update is the ability to create proper Symlinks.

While these are personal preference, I suggest making a few handy symlinks in your WSL users home directory.

Here are some examples of doing this:

ln -s /mnt/c/Users/YOURUSERNAME/Desktop ~/desktop ln -s /mnt/d/Development ~/dev ln -s /mnt/d ~/storage ln -s /mnt/d/Downloads ~/downloads

Now, assuming you have some type of organization with all of your projects, we can simply cd ~/dev and off we go.

Additional Packages

Here are some packages I recommend grabbing with sudo apt-get install .

screen

subversion

htop

dos2unix

Or for those who just want to take my word for it and blindly install them all:

sudo apt-get install screen subversion htop dos2unix

Conclusion

I realize some of the things above are personal preference, but I thought this would be a decent starter point for those who are interested in getting up and going with WSL and ditching our old ways of relying on Cygwin/Babun.

I plan on updating this post with additional information as I find the time for it and as I stumble upon things. I’m only about a day and a half into switching to Windows 10 but I’m quite happy with it now that WSL is usable.

I will work on cleaning up my dotfiles and pushing my new configuration to GitHub. Please, if you lurk on me, do not use the dotfiles currently on my GitHub. They are not “WSL-ready” and may cause some annoyances.

[Edit]