WSL 1 has faster cross-file system I/O than WSL 2, but it lacks lots of compatibility features, but even with WSL 1 the performance is still noticeably reduced when accessing the windows file system from within.
I have tried lots of things in the past, also before containers and WSL 1/2: VM with samba share, VM with NFS share, VM with Samba share and OverlayFS with vendor/non-code parts mounted from the Linux file system, rsync adapter, etc. But it is always slow, no performant solutions there.
There had been two reasons for why I wanted to have this hybrid approach: 1) The actual source code should reside on the Windows native file system (which I also maintain and back-up) and 2) Windows programs with their UI should be used to edit the files, with the exception of Linux tools that would be invoked inside the Linux system.
Both problems can be solved though:
The source code can be stored on the Windows native file system, but a work copy of it is replicated into the Linux file system. Using git is the right approach for this: The source code should be in version control anyway, the repository is cloned and a work copy is checked out into the Linux file system. Changes there can be easily pushed back to the repository.
Files editing shouldn’t be affected by the slow I/O when accessing those files on the WSL Linux system from native Windows programs.
VSCode offers something cool here though: It is installed and used as native Windows program, but it can also install a server in the WSL system, and use it more efficiently from within.
My workflow currently looks like this:
- Private GitLab server for hosting the repositories (mostly used for Trellis deployments, but it is helpful for development, too). GitHub now also offers free, unlimited private repositories by the way (if I get this right).
- Clone and check out a working copy from the external repository into the WSL Linux file system.
- Use VSCode with WSL support enabled to work with the source code, use Docker for Desktop with WSL support to run containers inside WSL for full performance.
- Push changes to the working copy back to the external repository, VSCode does this also very nicely.
Note: Everything listed above can also be achieved without VSCode, as with singular tools like git. I like what IDEs offer, but I don’t want to be dependent on one.