If you are anything like me, you might have given Google Antigravity a go, as I did in a recent post, and decided that there is not yet any WSL support given the extension marketplace specifically says This extension is not compatible with Antigravity.
However… it turns out that even if this is the case, the Remote-WSL: Connect to WSL option still appears in the command pallet, and is usable even without the extension installed?!
I planned on blogging being one of my relaxing hobbies while sailing around the Atlantic Ocean ⛵, and though we managed to keep a sailing blog up to date I found it extremely hard to write tech-related blogs while crossing oceans without a speedy or any internet connection.
The setting (of writing these blog posts) is rather beautiful, but to date, I have only written a single blog post when without a connection at all on this blog, now doubling that list to 2 with this post 🎉.
This was not because I didn’t have things that I wanted to write about, but rather that unless you are prepared well, there always seemed to be some element of my blog post writing process that would require access to something that is online and not on one of my local devices, or that only using local devices just ended up being a giant pain 🤦.
It’s no secret that I develop using Windows and WSL. For the past few years, I have also primarily used VSCode as my go-to development environment.
Between 2012 and 2018 I mainly used Jetbrains IntellijJ IDEA, but I found the speed of VSCode (launched in 2015), along with the modern design and vibrate plugin ecosystem, to win me over.
Every now and again I have found myself dipping back into the suite of Jetbrains IDEs, primarily for their high-quality code refactoring tools, nothing that I have seen in the VSCode ecosystem has quite lived up to this functionality.
This is exciting, as it’s advertised as “lightweight” with code processing engines running separately, similar to what is done in VSCode. But also contains their “20 years of experience developing IDEs”, which I hope will maintain the high-quality refactoring tools. Not to mention built-in “distributed” working modes for remote development, thus built-in WSL project integration.
So here is a very first look at using Fleet with a project in WSL2 land.
The Windows developer experience has evolved quite allot in the last 5-10 years. I now spend most of my development life running Windows with WSL2 and using Windows Terminal and winget. So here are a few pointers from my experiences so far.
WSL (WSL2)
WSL2 is what you want! The first version of WSL was a step in a great direction, but had many cons, such as IO performance. It should be fairly easy to install and will provide you a full Linux Kernel accessible from within Windows.
WSL also has access to your Windows filesystem via a mount at /mnt/c. Generally if you are using Linux tooling, you’ll want your file access to remain in the Linux file system. For example, I have almost all of my git repositories checked out in my Linux file system. For the odd repository that I use mainly Windows tooling I leave in Windows land.
VSCode seems to be one of the up and coming IDEs over the last year. I personally switched from Jetbrains IDEs to VSCode fo most of my development work at some point in 2020.
Apparently up until now I have avoided running the PHP debugger Xdebug. I had to do a little search around to figure out the correct settings for my setup decided to write them down in this handy blog post.