Warning: This post is over 2 years old, please reference newer guides for exact instructions, this is purely for my thoughts on the technology.
If you are here just to read up on how to configure ddev with WSL 2, click here.
The tech release of WSL 2 is out and now we have our first look at the future of development on Windows. Anyone not doing .NET programming has most likely felt let down by programming natively on Windows at some point or another. As a developer with strong focus in web technologies, you can count me among those people. Running a WAMP stack is significantly different from the LAMP or LNMP stacks that I am typically deploying to. And along came WSL.
Why Is Windows Important?
Personally, I am of the opinion that the only real option for buying a production ready machine for working on web technologies right now is buying a Mac. Important applications to the software development process are typically limited to Mac and Windows platform like Photoshop and Sketch for mockups, high quality git clients like Fork and Sourcetree, and first-class support.
Sadly, Window's architecture is nothing like servers we host our applications run on. And git bash, MSYS, and Cygwin are a nonperfect solution. And that's truly a shame. Microsoft has been making amazing strides in making fantastic hardware with their Surface lineup, especially the laptops. We need competition to not have Apple take for granted the developers who purchase Macs as their only option.
WSL 1
When WSL 1 came to Windows 10, I saw an interesting entry point to running the *NIX focused tools for development. For example, in Drupal development, you'll find that things like Drush assume that your system provides bash on your system. To make matters worse, if you use Windows native git clients, your line endings will consistently get messed up.
So, I thought to myself, WSL looks to be a good answer to a lot of issues that comes with developing on Windows. I install my distribution and add my SSH key to the Linux user it provides and clone my first repo. I immediately noticeable that git performance is poor. Doing research into this, the file system performance of WSL is not great due to implementing Windows file system access and storing the root FS in NTFS. Icing on the cake was how you needed to configure accessing the Docker daemon inside of WSL. WSL 1 proved to not be enough to work efficiently in Windows.
Almost Custom Tailored
It's not often when a company announces a product that seems to be tailored exactly to your complaints. That was exactly what WSL 2 was. Instead of converting syscalls, we now have a Hyper-V based Linux systems to work with directly. And Docker engine could also now use these to build its containers with performance improvements in the 10x scale for Symfony PHP applications according to Docker's blog. Now that just sounds fantastic. Now let's test those claims, shall we?
Setup with ddev
This assumes you've followed Microsoft's directions for enabling WSL2 and created a Linux instance for yourself with WSL2. Then make sure you have installed Docker Edge in Windows. And you have configured VS Code with the WSL remote.
Fire up the settings to Docker first and enable the WSL2 backend:
Then enable the sharing of the Docker daemon here:
Now we can fire up VS Code with our WSL Remote:
Now we can open up the terminal to WSL and install PHP 7.3, mysql-client, and composer:
sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt install mysql-client php7.3 php7.3-cli php7.3-json php7.3-pdo php7.3-mysql php7.3-zip php7.3-gd php7.3-mbstring php7.3-curl php7.3-xml php7.3-bcmath
wget https://raw.githubusercontent.com/composer/getcomposer.org/76a7060ccb93902cd7576b67264ad91c8a2700e2/web/installer -O - -q | php -- --quiet
chmod +x composer.phar
sudo mv composer.phar /usr/local/bin/composer
Installing ddev will require you to first install brew:
sh -c "$(curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install.sh)"
Then you can install ddev with:
brew tap drud/ddev
brew install ddev
Now you can create the site source somewhere on your WSL instance. Alternatively, download your preexisting site source from git.
composer create-project drupal-composer/drupal-project:8.x-dev repo --no-interaction
cd repo
Now use ddev to setup the site and respond with drupal8 as the config and web as the docroot, which should all be detected as the default values.:
ddev config
Finally, we can bring the site up and do a install.
ddev start
./vendor/bin/drush site:install -y
That's it, your site should be locally accessible. The DNS routing even works! This is the most seamless Drupal setup I've ever had in Windows. No need to switch between 2 different shells either. You can use git, docker, composer, shell scripts, and drush all from the same place. Composer and git performance is leagues ahead of WSL1, it's head to head with Linux and macOS.
Performance
While I don't have number to validate the 10x claim to WSL1 since setting up on WSL1 is much more time consuming, I can validate the performance is inline with full Linux VM. This most likely has to do with vendor file loading depending heavily on FS performance. Now that the file system has near native performance, the performance penalty has gone away. I would not use WSL2 as a production host, but I would definitely recommend it now for development if you need more software support than Linux has to offer.
Note on VS Code
I used to feel very very strongly against VS Code. The idea of using a Chrome instance to edit text just feels like a abhorrent waste of computing resources. But with their strong integration with WSL 2, it demonstrates the thing was so great at with the original Visual Studio IDEs. Could this be done with native UI toolkits to not waste RAM needlessly? Of course. But this is at least a unique experience that can't be offered by any text editor.
A workaround to use Linux development tools while staying in Windows, without any crazy configuration. Perfect Docker integration. Fast file system performance. Git always uses the correct line endings. While I wish Windows was able to do all of this natively, us macOS users have been using Docker and Vagrant anyway, what difference does it make now? Now it's entirely the preference of the user. My preference is still a powerful Mac, but a custom-built Windows workstation would now be a good option for my uses.