Drupal development on Windows

drupal #windows

Recently I wrote on how I replaced my MacBook Pro with a PC and still being productive when developing on several Drupal environments.While Pop_OS! is a wonderful Linux distro, I decided to give Windows a try. The primary reasons were the usual: hardware.

The drivers are optimized to work on Windows and some small features that are nice-to-have only work on this controversial OS: Login with an infrared camera (Windows Hello), a solid workspace with several monitors (maybe this is the most important reason), better Dolby sound from the speakers and battery optimizations. Nothing critical really, but things that improve the experience.

What means to have a productive development environment?

This:

1. Bash command line.
2. Fast docker environment (without unison, I've had enough problems with it already).
3. Working git
4. Be able to launch several development environments, fast, from command line, and use custom domain names to access them and its related services.
5. A good editor, like Sublime Text or Visual Studio Code. (I know, I don't use PHP Storm and don't want to).

Since I had tried WSL before (and failed), I decided to get rid of it and move directly to install a VM.

An Ubuntu server checks first three items in the above list, but the next two can get messy. Sharing source code files with the Windows host as a Samba share defeats the purpose because its bad performance, symlinks weirdness, among other things. Sharing it using sshfs could be an option, but then how could I control docker?

Editor

The solution came on a recent iteration on Visual Studio Code: Remote code extensions, specifically, Remote Coding via SSH. This extension allowed me to open remote directories through SSH and work with them. This is not like running Dreamweaver to edit files on a server (remember?). It works splitting the editor in two pieces, a client (the UI) and a server, where the indexing and language processing extensions run. The result is a very responsive editor, while working remotely with all the extensions I would normally use. Even the integrated terminal in the editor opens automatically a bash prompt in the server, a really useful feature.

This remote feature in Visual Studio Code gives me the full Linux experience right from the editor.

However, I normally access docker websites using custom URLs, a pretty common practice. If using docksal, for example: super-awesome-client.docksal, db.super-awesome-client.docksal, etc., you get the idea. I needed to find a way to re-route custom URLs to my VM.

Networking

On a Mac or on Linux this would work out of the box after installing docksal (or lando or whatever docker wrapper you use). I wanted this to work the same way:

• I didn't want to configure each custom website manually
• This had to work on new sites created with docksal
• Should work on any network

To achieve this transparent routing, I needed a static IP for the VM, so I could always reference it if I was at home, at a coffee shop, or in an airport. I'm using Hyper-v, so I created a NAT using the instructions below:

Windows 10: How to setup NAT network for Hyper-V guests?



Then in the VM, configured the static IP address using netplan, created file /etc/netplan/01-netcfg.yaml (I used the same IP address as the guide to create the NAT above).

yaml

network:
ethernets:
eth0:
dhcp4: no
dhcp6: no
addresses: [192.168.200.11/24]
gateway4: 192.168.200.1
nameservers:
addresses: [8.8.8.8]

After **enabling the ssh server in the VM**, and configuring my ssh keys I was able to jump into the server from Windows very quickly, or even configure [ConEmu](https://conemu.github.io/) or the new [Windows Terminal](https://github.com/microsoft/terminal) to automatically connect to ssh.

To access the web servers running in docker containers created with docksal, **I installed a DNS proxy**: [Acrylic DNS Proxy](http://mayakron.altervista.org/wikibase/show.php?id=AcrylicHome), and used this `hosts` configuration:

192.168.200.11 *.docksal

## Visual Studio Code Configuration

In Visual Studio Code I installed the [Remote Development extensions for SSH](https://code.visualstudio.com/docs/remote/ssh). The configuration was straight forward and worked really well (the extension guides you until you are successfully connected to a SSH server).

Huge Drupal projects were indexed really fast and the performance when browsing them was like working on Linux. Debugging worked out of the box (this thanks to Docksal configs, but still, using `docker-compose` shouldn't be a problem).

The only downside I've found is that I can't commit, push or pull using the editor, which is not a big deal since I can use the integrated terminal. From the [documentation](https://code.visualstudio.com/docs/remote/ssh#_known-limitations):

> If you clone a Git repository using SSH and your SSH key has a passphrase, VS Code's pull and sync features may hang when running remotely. Either use an SSH key without a passphrase, clone using HTTPS, or run git push from the command line to work around the issue.

I ended up creating an SSH key for my repos without a passphrase.

## Recap

Working on PHP natively on Windows it is still impossible, but using a VM and Visual Studio Code with Remote Code extensions works very well, with the price of more memory usage, but memory is cheap now, and that is one of the reasons I left Apple in the first place: to have an upgradable development computer.

One unexpected bonus is that I can recover from suspend and the VM will load up with all services that were running, something that in Linux didn't happen; I had to to run `fin up` or `docker-compose up` again after the laptop woke.

## Aside: WSL2

The Windows Subsystem for Linux v2 is _about_ to be released, which uses a custom Linux Kernel in a very lightweight VM (it is already in Windows Internals fast ring, but expected to reach public release until 2020).

In theory, it has all the same good points of this setup with a VM, and seems so be a great setup for a [future development environment](https://www.youtube.com/watch?v=A0eqZujVfYU) because of these:

* The VM file system can be accessed directly from Windows using a p9 file system (that alone is awesome).
* The performance is very close to native one.
* Shared memory and processor cores.
* Much tighter integration, it is possible to run windows programs from within the VM.

This technology can really change the development experience on Windows, lets see if it is up to the expectations when it is released (because I won't subscribe to the fast ring in my main development computer).

## Stranger things

While setting the environment [I found an error](/en/blog/git-errors-when-using-hyper-v) that didn't allow me to clone big repos or to push changes. It turned out to be a bug in my WiFi drivers. So if you find the error below and have an Intel WiFi card, update your drivers.

$ git clone git@somrerepo-bla-bla.git
Cloning into 'somedir'...
error: RPC failed; curl 56 GnuTLS recv error (-12): A TLS fatal alert has been received.
fatal: The remote end hung up unexpectedly