Setting Up A Windows Development Environment

Setting Up A Windows Development Environment

Nick Reynolds
Published 2025-03-23

Introduction

This guide walks you through setting up a modern development environment on Windows, suitable for developing Node.js/Javascript/Typescript projects (including React, Next.JS, Svelte/SvelteKit), Python Projects (including Django, Flask, FastAPI), cloud native projects (including AWS, Azure, GCP), and indeed many other stacks both inside or outside of containerized environments, supporting microservices architectures, and optionally integrating with CI/CD pipelines (basically anything covered on goldnode.com!).

This is not likely to be the best guide for you if you are developing native, monolithic Windows applications in C#, VB.NET, or indeed any other Windows-specific language or framework.

Why use Windows at all?

In recent years there has been huge developments in the Windows ecosystem supporting Linux within Windows development IDE (after the release of Visual Studio Code) and the continuously improving Windows Subsystem for Linux (now WSL2).

With Linux (or variants) being the Operating System that many cloud computing components and many development frameworks are built on this opens up a whole new world of development opportunities for Windows users and for all but those who are locked into a Windows-only development environment I would strongly recommend a WSL2 setup even if you are staring off with little or no experience of Linux.

Windows with WSL2 is a great Operating System for modern development, and I'm writing this as a long time Linux user of 30 years, who has for the majority of that time used Linux as my primary desktop machine for virtually everything. If you are primarily a Windows user, and don't want to switch to Linux or a Mac for native development that's fine, there is really no need to, just follow this guide.

So is WSL2 Strictly Necessary?

The short answer is: no, it’s not strictly required. You can download and install install native Windows software for docker, git, node.js, python and many others. However, using WSL2 offers several advantages that can streamline your workflow, improve performance, and align your development environment more closely with production systems and is highly recommended.

Prerequisites

Before starting, ensure you have:

  • A fully updated Windows 10 (version 2004 or later) or Windows 11 machine with administrative access.
  • At least 8GB of RAM (16GB recommended) for smooth WSL2 and Docker performance.

Install and Configure WSL2

WSL2 allows you to run a Linux environment directly on Windows, which is great for development consistency and compatibility.

Enable WSL and Virtual Machine Platform

  1. Open PowerShell as Administrator (search for "PowerShell" in the Start menu, right-click, and select "Run as Administrator").
  2. Run the following command to enable WSL and the Virtual Machine Platform:
wsl --install
  1. Run the following to enable the needed features, just in case they have not already been enabled:
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
  1. Restart your computer.

Check WSL2 is Enabled and a Distribution is Installed

Open a PowerShell window again and type:

wsl --list --verbose

You should see something like this:

  NAME      STATE           VERSION
* Ubuntu    Stopped         2

(Depending on how it was installed, Ubuntu may have a release number attached, such as "Ubuntu-24.04", that's fine).

If you don't see anything, open the Microsoft Store and install Ubuntu from there.

The version here is important, as we need to ensure we are using WSL2, not WSL1. If under the VERSION column you see "1" then you need to switch to version 2:

wsl --set-version <distro-name> 2
wsl --set-default-version 2

If you see "2" then you are all set.

Configure the Ubuntu Environment

Start Ubuntu from the Start menu and update it:

$ sudo apt update
$ sudo apt upgrade

If this is your first experience of the Linux command line, just follow along for now. Once we are all set up you may want to look at the "Introduction to the Linux/Mac Command Line" guide on goldnode.com to get a better understanding of how it all works. As for these commands, the first one updates the list of available packages known to the package manager and the second one installs any updates for installed packages. sudo tells the system to run the command with super user privileges. The dollar sign is the prompt from the command line, you don't need to type it.

Install additional packages

There are a few packages that are useful to have installed and ready to go:

$ sudo apt install curl wget

These tools are useful for downloading files from URLs, but perhaps more importantly in your development environment, for quickly making HTTP requests to endpoints for testing and debugging. A lot of the functionality is duplicated in these tools, but they are so slim that it's not a problem and it's useful being able to copy and past examples form the web which use either.

$ sudo apt install zip unzip

Although we already have a number of archive tools installed, it's handy to have the zip and unzip tools available too.

$ sudo apt install git -y

Git is the most popular version control system, even in the unlikely event that you won't be using it for your project, it's a very useful tool to have available and also allows you to checkout and test code from other projects.

To save you a configuration step later, it's worth also setting your name and email address in the git configuration now:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Optional, but highly recommended:

$ sudo apt install build-essential

This will actually install a number of development tools including compilers and linkers, which may not be immediately obviously needed if developing in high level languages like Python or Node.js/(Javascript/Typescript), but there are many occasions when these may be needed to build supporting software, or libraries. Having them available from the start may save a lot of time and frustration later, especially if unfamiliar with the Linux environment.

Install Visual Studio Code

VS Code is a lightweight, extensible code editor that integrates well with WSL2.

Even if you have another IDE or editor of choice, even one originating from a Visual Studio Fork, I'd still highly recommend installing VS Code. There are many reasons why you may finding yourself using it during development even if you chose to use a different one as your primary editor.

  1. Download the VS Code installer from https://code.visualstudio.com/.
  2. Run the installer and follow the prompts. When asked to "Add to PATH" check the box for ease of starting VS Code from the command line.

Installing the WSL Extension in VS Code

  1. Run the Visual Studio Code from the regular windows start/search menu.
  2. Go to the Extensions view (Ctrl+Shift+X or click the Extensions icon in the sidebar).
  3. Search for "WSL" and install the "Remote - WSL" extension by Microsoft.
  4. Reload VS Code if prompted.

To now work on our WSL projects we have a few options, if you open the command palette (Ctrl+Shift+P) and type WSL you'll see one of the options is:

  • Connect to WSL - This will open a new VS Code session connected to the WSL2 environment so we can then open files of folders from the WSL2 environment.

However what can be more convenient when developing and navigating in a a WSL2 environment is to start your visual code session from within a Ubuntu terminal after navigating to the project directory, so we'll try that instead so close your current VS Code window before continuing.

Starting VS Code from a Ubuntu Terminal

Open a new Ubuntu terminal, and we'll create a new directory for our dummy project, navigate to it, and then start VS Code from there.

$ mkdir dummy-project
$ cd dummy-project
$ code .

You should now see the VS Code window open with the dummy-project directory loaded, and you can now start working on your project.

Visual Studio Code is now running on your Windows machine, but it's connected to the WSL2 filesystem using the WSL2 extension, all transparent to you.

Remote - SSH Development (optional)

As well as the WSL2 extension, VS Code also has a Remote - SSH extension which allows you to connect to a remote machine over SSH and work on it as if it were local. If you're not too sure what that means, it's not something you need to worry about right now, but if you're interested install the "Remote - SSH" extension and follow the instructions to connect to a remote machine in much the same way as you are connecting to a WSL2 environment.

Plugins/Settings and Remote/WSL Development

When using Visual Studio Code (VS Code) on Windows with remote development features like Remote - SSH or Remote - WSL, the way extensions (plugins) and settings are managed changes compared to a local Windows-only setup. These remote extensions allow VS Code to split its functionality between your local Windows machine and the remote environment (e.g., a WSL2 distro or an SSH-connected server).

Overview of Remote Architecture

VS Code uses a client-server model for remote development:

  • Local VS Code (Client): The VS Code instance running on Windows handles the user interface (UI), such as the editor window, menus, and sidebar. This is what you see and interact with.
  • Remote Server: A lightweight VS Code server runs on the remote environment (e.g., WSL2 or an SSH-connected machine). This server handles file operations, terminal sessions, and tasks that need to execute in the remote context.
  • Communication: The client and server communicate over a secure channel (e.g., WSL2 interop or SSH protocol), allowing seamless integration despite being on different systems.

This split affects where extensions run and how settings are applied.

Extensions (Plugins) in Remote - SSH and WSL

Extensions in VS Code can run in two places: the local client (Windows) or the remote server (WSL2 or SSH host). The location depends on the extension’s purpose and how it’s installed.

  • When you open a WSL2 workspace (e.g., code . in a Ubuntu WSL2 shell) or connect to an SSH host, VS Code detects the remote context and prompts you to install recommended extensions on the remote server if they’re not already present.
  • You can see this in the Extensions view: extensions installed locally are marked with a "Local" badge, while those on the remote server have a "WSL" or "SSH" badge.
  • Example: If you install "ESLint" while in a WSL2 workspace, it’s installed in WSL2, not Windows, ensuring it uses the WSL2 node and eslint binaries.

Settings in Remote - SSH and WSL

Settings in VS Code are managed at different scopes (user, workspace, remote), and their application changes slightly in remote setups.

How Settings Are Organized

  1. User Settings:
    • Stored in ~/.config/Code/User/settings.json on Windows (e.g., C:\Users\YourName\AppData\Roaming\Code\User\settings.json).
    • Apply globally to all VS Code instances, including local and remote workspaces, unless overridden.
    • Example: "editor.fontSize": 14 applies everywhere.
  2. Workspace Settings:
    • Stored in .vscode/settings.json within a project folder.
    • Apply only to that workspace, whether it’s local (Windows) or remote (WSL2/SSH).
    • Example: "eslint.enable": true in a project’s .vscode/settings.json applies to that project.
  3. Remote Settings:
    • Stored in a remote-specific settings file on the remote environment (e.g., ~/.vscode-server/data/User/settings.json in WSL2 or on the SSH host).
    • Apply only when connected to that remote environment and override user settings for remote-specific behavior.
    • Example: "terminal.integrated.defaultProfile.linux": "bash" set in WSL2’s remote settings.

How Settings Are Applied

  • Precedence: Settings follow this order: Remote > Workspace > User. If a setting is defined in the remote environment, it takes priority over the same setting in your Windows user config.
  • Syncing: The "Settings Sync" feature (enabled via a Microsoft or GitHub account) can synchronize user settings between Windows and remote environments, but remote-specific settings remain separate.
  • Remote-Specific Adjustments:
    • When you connect to WSL2 or SSH, VS Code loads the remote server’s settings. You can edit these via the UI (Ctrl+,) while in the remote workspace, and changes are saved to the remote settings file.
    • Example: Setting "python.pythonPath": "/usr/bin/python3" in WSL2 ensures the Python extension uses WSL2’s Python, not Windows’.

If this is your first time working with VS Code, and particularly with remote or WSL development, don't worry if this is not clear at this stage, it is useful to however to have a little knowledge in the back of your mind, for example when you make changes to the settings and see they exist in three different places.

Adding support for Languages and Tool kits

Python

There's very little to do here, python3 should already be installed, you can check with:

$ python3 --version

We should though ensure we have the venv tool installed, for creating and managing virtual environments:

$ sudo apt install python3-venv

If you'll be developing with Python, a good tip is never to install modules globally, but to use a python virtual environment (such as venv) or develop within a containerized environment, this ensures you have a consistent development environment and will avoid potential conflicts with other projects and modules. Installing modules globally could prevent a previously working project from working if the global version is changed and it also make things very difficult keeping on top of what modules a project is using when it comes to deployment, CI/CD, and working with other developers.

Node.js

Follow the guide here to add Node.js development support to your environment.

Docker

There are a couple of easy methods to easily add support for development in Docker containers, full details can be found here.

Cloud Tooling

Follow the appropriate guides to add support for the cloud tooling for the providers you are going to be using:

Provider Guide
Amazon Web Services CLI Installation Guide
Microsoft Azure CLI Installation Guide
Google Cloud Platform CLI Installation Guide
Page 1 of 5

© 2025 Goldnode. All rights reserved.