When working with JavaScript-based frameworks, even the Microsoft documentation recommends using Windows Subsystem for Linux. If you're not familiar with WSL, it enables you to run a Linux distribution of your choice and use a BASH command line right from your Windows machine. Just recently, WSL even got support to run GUI Linux GUI applications (X11 and Wayland) on Windows in a fully integrated desktop experience.
There are multiple reasons why WSL is the recommended choice for JS development:
Better performance speed.
System call compatibility.
Alignment between your local development environment and deployment environment (which is often a Linux server).
The WSL was designed and built by the Windows Kernel Team and delivered in partnership with Canonical, to help Windows developers use the rich Linux developer ecosystem and tools, without having to boot into another operating system or VM. This is particularly useful for web developers.
WSL 1 vs WSL 2
WSL 1 implements a virtualized Linux kernel interface on top of the Windows NT kernel. In essence, it operates independently of the actual Linux kernel – when an application initiates a Linux-specific system call (syscall), WSL interprets and converts it into the corresponding Windows syscall.
WSL 2 represents a significant revamp of the underlying architecture and it is using an actual Linux kernel inside a managed VM. It also has support for full system call compatibility and better performance than WSL 1.
Installation
Installing WSL is a matter of executing a command in the PowerShell or Windows Command Prompt. In administration mode, use the following command:
wsl --install
After the machine restart, you will be able to run the newly installed Linux distribution. By default, the installed Linux distribution will be Ubuntu. This can be changed using the -d flag: wsl --install -d . To see a list of available Linux distributions available enter: wsl --list --online .
To install a Linux distribution that is not listed as available, you can import any Linux distribution using a TAR or appx file.
After installing the WSL, you can use wsl.exe command line tool for managing WSL and interacting with WSL distributions on a Windows system. You can use wsl.exe to run specific Linux commands, launch Linux distributions, and manage various aspects of WSL, such as setting the default distribution, managing network settings, and more.
Each installed WSL distribution has its own executable file, such as ubuntu.exe for the Ubuntu distribution, debian.exe for Debian, and so on. These executables allow you to run a specific Linux distribution directly from the Windows Command Prompt or PowerShell, without needing to specify the distribution name or other options. They are shortcuts to launching a particular WSL distribution and starting a Linux shell within that distribution.
Using the Terminal
Whenever a new WSL Linux distribution is installed, a new corresponding instance will be created inside the Windows Terminal. Windows Terminal supports customization of a large number of preferences like: keyboard shortcuts, themes, color schemes etc.
Always store your project files in the WSL file system if you plan to use them from the Linux command line(npm or Node.Js commands for example). WSL file system root directory will be available in the following location: \\wsl$\<DistroName>\home\<UserName>.
Mount points for hard drives on the local machine are automatically created and provide easy access to the Windows file system: /mnt/<DriveLetter>/. This means it is possible to access files across the operating systems, but it is not recommended, since it can significantly slow down performance.
Using Git
Git comes already installed with most of the Windows Subsystem for Linux distributions. Check your current version with git --version and update if needed.
Recommended approach is installing Git for Windows which includes Git Credential Manager. Git Credential Manager (GCM) is a secure Git credential helper that enables multi-factor authentication support for GitHub repos, Azure DevOps, Azure DevOps Server, and Bitbucket. Note: In order to use GCM with WSL you must be on Windows 10 Version 1903 or later.
When using this setup, the host operating system (Windows) is used to store credentials, which means that your Windows applications and WSL distributions can all share those credentials, removing the need to sign-in multiple times. To get everything working few additional steps are required:
Inside your WSL installation, run the following command to set GCM as the Git credential helper:
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe". Note: the location of git-credential-manager.exe may be different in your installation of Git for Windows.If you intend to use Azure DevOps you must also set the following Git configuration inside of your WSL installation:
git config --global credential.https://dev.azure.com.useHttpPathtrue.
Setting up the IDE
In today's modern IDEs, there is a noticeable trend of including support for remote development. With remote development, the IDE is installed as a backend service on the host machine. It will load the project on the host side, without displaying the user interface. On the client side, IDE is acting as a thin client and connects to the backend service on the host. All the processing is done on the host/server side and the full working user interface is displayed on the client side as if the IDE was running locally.
This concept complements quite nicely with the WSL quite nicely, and luckily IDEs like WebStorm and VS Code support connecting to WSL host for remote development.
VS Code
To remotely work within WSL you will need to install the WSL extension. With this extension installed, VS Code’s UI runs on Windows but you run and debug your project in WSL. This also means that all the commands, extension and VS Code terminal run on Linux.
To open the project in VS Code, open the WSL in Windows Terminal, position yourself in the project folder and run the following: code .
Resources: