Running Windows 10 in a Yoast environment

Recently, I switched from a MacBook Pro to an MSI GS70 as my workstation. This meant that I had to reconfigure my development environment in Windows. This had to be done in a way so that I still had access to the same tools that my colleagues use on their Apple machines.
In this post I’d like to share my experience setting up my Windows system, the issues I ran into and how to solve them.

The reason I switched was because I had difficulty to read the text on the screen of my Mac. The technique they use to render fonts, make them appear blurry to me. Windows does the same with their Cleartype technology, but fortunately I can turn it off there, which makes fonts readable for me.

Most software will actually work on both platforms. E.g. browsers, mail clients, PHPStorm, Slack, Skype, 1Password and a number of other tools we use on a daily basis work fine. They’ll install just as easily on a Windows system as on a Mac. An added advantage is I can run software that doesn’t run on a Mac, like Edge and Internet Explorer, so we can use those for testing purposes.
However, there are several scripts and tools, especially those that we run from the terminal, that work a bit differently on a Windows machine.

Powershell

The first thing to keep in mind is to forget about CMD and use PowerShell instead. Using CMD.exe often has issues with the PATH variable not being set automatically. This is unlike OSX beamer with a cable .and other Unix-based operating systems, where this is automatically adjusted. Fortunately Windows 10 ships with PowerShell, which is a good replacement for the Terminal application I
used to use on OSX. The only thing you have to keep in mind is starting an elevated PowerShell when installing software. A nice advantage of PowerShell is that it uses the same commands as Unix, which means the user-experience isn’t all that different from OSX.

VVV

For WordPress development we use VVV, Varying Vagrant Vagrants. Setting this up on Windows is quite the same as on OSX, as long as you run it from PowerShell. Running the setup from CMD will fail because it won’t find the required Virtualbox, even if it’s installed properly.

Hosts file

The main thing I bumped into with PowerShell was the rights management on the hosts file in Windows. Make sure you set this to full control for the current user, so you can run `vagrant up` without errors if you run. When running it as an administrator you should have the right settings; If you run it as a user without administrator rights, make sure to set up the permissions for the hosts file, so it can be updated. This way, the hosts file can be updated properly with the necessary entries for Vagrant.

Virtualbox

Besides running a Vagrant setup, Virtualbox comes in handy when trying to quickly setup a virtual machine. I have an Ubuntu virtual machine handy in case I need to run a Unix based script that doesn’t run on Windows. I have to admit I hardly use the virtual machine since my Windows machine was properly set up.
There are still some build scripts that require a library that isn’t available on Windows. Gettext is one of those, which is used in some Grunt tasks here at Yoast. For those rare occasions, a virtual machine can be used to run these tasks. All other Grunt tasks we use at Yoast work fine.

Issues I ran into

There are a few small issues I ran into with my new machine:

Line feeds

The issue with the most impact is how line feeds are saved. Line feeds in Windows differ from the ones on Unix based systems. This can become a bit annoying if you pull a branch from Git and all line-endings are different. This means that with every commit, every line in the file is changed, because the line-endings differ. The best way to tackle this, is by using PHPstorm and changing the line-endings to LF. This is the Unix default used before committing. Make sure you also check if Git is configured properly on your local machine so it doesn’t convert line-endings.
This works pretty well, but I used to get warnings when I did a commit that line-endings were converted, and ended up with CRLF line-endings. The easiest way to fix this is to add a .gitattributes file with a declaration of line-endings that you want to have. You don’t have to commit it to the project’s Git repository for this to work, but you can do this to make sure everybody has the same settings.

Maximum filename length

Another minor thing I ran into, was the maximum filename length. Some of our projects have files with pretty long pathnames, especially those that are included in a node_modules directory. Windows, or rather its filesystem, has an annoying limitation of the length of filenames. When running npm install it will copy those files to the correct destination, but deleting them afterwards becomes nearly impossible. Luckily I found a simple tool called ‘rimraf,’ that basically mimics the Unix `rm -rf` command. Even though I don’t use it very often, it can come in handy when removing files with names that are too long.

Most other issues are nothing more than commands that work a bit differently, which you can counter with a quick search on Google.

Hardware compatibility

The only thing that is hard to overcome, is hardware compatibility. This doesn’t really hinder me in my day to day work. Connecting an Apple display with a standard DisplayPort isn’t going to work. Using the Apple TVs to cast my screen to from Windows doesn’t work either. However, those issues are fixed easily by using a different monitor or by connecting my system to a beamer with a HDMI-cable.

Conclusion

All in all, plugin development at Yoast isn’t that different on a Windows machine compared to working on an Apple. Especially after I set it up to work the same way as a MacBook (as much as possible).

Having a Windows machine in an all Apple environment has its advantages as well when it comes to running software that isn’t available on a Mac. But the main advantage for me is I don’t longer have difficulty reading the text on my screen.