You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: hub/dev-environment/javascript/nodejs-on-windows.md
+14-10Lines changed: 14 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,15 +2,22 @@
2
2
title: Set up Node.js on native Windows
3
3
description: A guide to help you get your Node.js development environment set up directly on Windows.
4
4
ms.topic: article
5
-
ms.date: 12/20/2023
5
+
ms.date: 11/26/2024
6
6
---
7
7
8
8
# Install Node.js on Windows
9
9
10
-
If you are new to developing with Node.js and want to get up and running quickly so that you can learn, follow the steps below to install Node.js directly on Windows.
10
+
This guide will help you to install Node.js in a Windows development environment.
11
11
12
-
> [!NOTE]
13
-
> If you are using Node.js professionally, find performance speed and system call compatibility important, want to run [Docker containers](../docker/overview.md) that leverage Linux workspaces and avoid having to maintain both Linux and Windows build scripts, or just prefer using a Bash command line, then [install Node.js on Windows Subsystem for Linux](./nodejs-on-wsl.md) (more specifically, WSL 2).
12
+
For those who prefer using Node.js in a Linux environment, see [Install Node.js on Windows Subsystem for Linux (WSL2)](./nodejs-on-wsl.md).
13
+
14
+
Consider the following when deciding where to install and whether to develop with Node.js in a native Windows versus a Linux (WSL 2) environment:
15
+
16
+
-**Skill level**: If you are new to developing with Node.js and want to get up and running quickly so that you can learn, [install Node.js on Windows](./nodejs-on-windows.md). Installing and using Node.js on Windows will provide a less complex environment for beginners than using WSL.
17
+
-**Command line client tool**: If you prefer PowerShell, use Node.js on Windows. If you prefer Bash, use Node.js on Linux (WSL 2).
18
+
-**Production server**: If you plan to deploy your Node.js app on Windows Server, use Node.js on Windows. If you plan to deploy on a Linux Server, use Node.js on Linux (WSL 2). WSL allows you to install your preferred Linux distribution (with Ubuntu as the default), ensuring consistency between your development environment (where you write code) and your production environment (the server where your code is deployed).
19
+
-**Performance speed and system call compatibility**: There is continuous debate and development on Linux vs Windows performance, but the key when using a Windows machine is to keep your development project files in the same file system where you have installed Node.js. If you install Node.js on the Windows file system, keep your files on a Windows drive (for example, C:/). If you install Node.js on a Linux distribution (like Ubuntu), keep your project files in the Linux file system directory associated with the distribution that you are using. (Enter `explorer.exe .` from your WSL distribution command line to browse the directory using Windows File Explorer.)
20
+
-**Docker containers**: If you want to use Docker containers to develop your project on Windows, we recommend that you [Install Docker Desktop on Windows](https://docs.docker.com/desktop/setup/install/windows-install/). To use Docker in a Linux workspace, see [set up Docker Desktop for Windows with WSL 2](/windows/wsl/tutorials/wsl-containers) to avoid having to maintain both Linux and Windows build scripts.
14
21
15
22
## Install nvm-windows, node.js, and npm
16
23
@@ -20,7 +27,7 @@ Besides choosing whether to install on Windows or WSL, there are additional choi
20
27
> It is always recommended to remove any existing installations of Node.js or npm from your operating system before installing a version manager as the different types of installation can lead to strange and confusing conflicts. This includes deleting any existing Node.js installation directories (e.g., "C:\Program Files\nodejs") that might remain. NVM's generated symlink will not overwrite an existing (even empty) installation directory. For help with removing previous installations, see [How to completely remove node.js from Windows](https://stackoverflow.com/questions/20711240/how-to-completely-remove-node-js-from-windows).)
21
28
22
29
> [!WARNING]
23
-
> NVM is designed to be installed per-user, and invoked per-shell. It is not designed for shared developer boxes or build servers with multiple build agents. NVM works by using a symbolic link. Using nvm in shared scenarios creates a problem because that link points to a user's app data folder -- so if user x runs `nvm use lts`, the link will point node for the entire box to their app data folder. If user y runs node or npm, they will be directed to run files under x's user account and in the case of `npm -g`, they will be modifying x's files, which by default is not allowed. So nvm is only prescribed for one developer box. This goes for build servers too. If two build agents are on the same vm/box, they can compete and cause odd behavior in the builds.
30
+
> NVM is designed to be installed per-user, and invoked per-shell. It is not designed for shared developer boxes or build servers with multiple build agents. NVM works by using a symbolic link. Using nvm in shared scenarios creates a problem because that link points to a user's app data folder -- so if user x runs `nvm use lts`, the link will point node for the entire box to their app data folder. If user y runs node or npm, they will be directed to run files under x's user account and in the case of `npm -g`, they will be modifying x's files, which by default is not allowed. So nvm is only prescribed for one developer box. This goes for build servers too. If two build agents are on the same vm/box, they can compete and cause odd behavior in the builds.
24
31
25
32
1. Follow the install instructions on the [windows-nvm repository](https://github.com/coreybutler/nvm-windows#installation--upgrades). We recommend using the installer, but if you have a more advanced understanding of your needs, you may want to consider the manual installation. The installer will point you to the [releases page](https://github.com/coreybutler/nvm-windows/releases) for the most recent version.
26
33
2. Download the **nvm-setup.zip** file for the most recent release.
@@ -90,9 +97,6 @@ If you plan to collaborate with others, or host your project on an open-source s
90
97
91
98
4. We recommend adding a [.gitignore file](https://help.github.com/en/articles/ignoring-files) to your Node projects. Here is [GitHub's default gitignore template for Node.js](https://github.com/github/gitignore/blob/master/Node.gitignore).
92
99
93
-
## Use Windows Subsystem for Linux for production
94
-
95
-
Using Node.js directly on Windows is great for learning and experimenting with what you can do. Once you are ready to build production-ready web apps, which are typically deployed to a Linux-based server, we recommend using Windows Subsystem for Linux version 2 (WSL 2) for developing Node.js web apps. Many Node.js packages and frameworks are created with a *nix environment in mind and most Node.js apps are deployed on Linux, so developing on WSL ensures consistency between your development and production environments. To set up a WSL dev environment, see [Set up your Node.js development environment with WSL 2](./nodejs-on-wsl.md).
100
+
## Node.js on Windows Server
96
101
97
-
> [!NOTE]
98
-
> If you are in the (somewhat rare) situation of needing to host a Node.js app on a Windows server, the most common scenario seems to be [using a reverse proxy](https://medium.com/intrinsic/why-should-i-use-a-reverse-proxy-if-node-js-is-production-ready-5a079408b2ca). There are two ways to do this: 1) [using iisnode](https://harveywilliams.net/blog/installing-iisnode) or [directly](https://dev.to/petereysermans/hosting-a-node-js-application-on-windows-with-iis-as-reverse-proxy-397b). We do not maintain these resources and recommend [using Linux servers to host your Node.js apps](/azure/app-service/app-service-web-get-started-nodejs).
102
+
If you are in the (somewhat rare) situation of needing to host a Node.js app on a Windows server, the most common scenario seems to be [using a reverse proxy](https://medium.com/intrinsic/why-should-i-use-a-reverse-proxy-if-node-js-is-production-ready-5a079408b2ca). There are two ways to do this: 1) [using iisnode](https://harveywilliams.net/blog/installing-iisnode) or [directly](https://dev.to/petereysermans/hosting-a-node-js-application-on-windows-with-iis-as-reverse-proxy-397b). We do not maintain these resources and recommend [using Linux servers to host your Node.js apps](/azure/app-service/app-service-web-get-started-nodejs).
Copy file name to clipboardExpand all lines: hub/dev-environment/javascript/nodejs-on-wsl.md
+12-11Lines changed: 12 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,32 +3,33 @@ title: Set up Node.js on WSL 2
3
3
description: A guide to help you get your Node.js development environment set up on Windows Subsystem for Linux (WSL).
4
4
ms.topic: article
5
5
ms.localizationpriority: medium
6
-
ms.date: 03/01/2024
6
+
ms.date: 11/26/2024
7
7
---
8
8
9
9
# Install Node.js on Windows Subsystem for Linux (WSL2)
10
10
11
-
If you prefer using Node.js in a Linux environment, find performance speed and system call compatibility important, want to run [Docker containers](/windows/wsl/tutorials/wsl-containers) that leverage Linux workspaces and avoid having to maintain both Linux and Windows build scripts, or just prefer using a Bash command line, then you want to install Node.js on the Windows Subsystem for Linux (more specifically, WSL 2).
11
+
For those who prefer using Node.js in a Linux environment, this guide will help you to install Node.js on the Windows Subsystem for Linux (WSL 2 is the recommended version).
12
12
13
-
Using Windows Subsystem for Linux (WSL), might also enable you to install your preferred Linux distribution (Ubuntu is our default) so that you can have consistency between your development environment (where you write code) and production environment (the server where your code is deployed).
13
+
Consider the following when deciding where to install and whether to develop with Node.js in a native Windows versus a Linux (WSL 2) environment:
14
14
15
-
> [!NOTE]
16
-
> If you are new to developing with Node.js and want to get up and running quickly so that you can learn, [install Node.js on Windows](./nodejs-on-windows.md). This recommendation also applies if you plan to use a Windows Server production environment.
15
+
-**Skill level**: If you are new to developing with Node.js and want to get up and running quickly so that you can learn, [install Node.js on Windows](./nodejs-on-windows.md). Installing and using Node.js on Windows will provide a less complex environment for beginners than using WSL.
16
+
-**Command line client tool**: If you prefer PowerShell, use Node.js on Windows. If you prefer Bash, use Node.js on Linux (WSL 2).
17
+
-**Production server**: If you plan to deploy your Node.js app on Windows Server, use Node.js on Windows. If you plan to deploy on a Linux Server, use Node.js on Linux (WSL 2). WSL allows you to install your preferred Linux distribution (with Ubuntu as the default), ensuring consistency between your development environment (where you write code) and your production environment (the server where your code is deployed).
18
+
-**Performance speed and system call compatibility**: There is continuous debate and development on Linux vs Windows performance, but the key when using a Windows machine is to keep your development project files in the same file system where you have installed Node.js. If you install Node.js on the Windows file system, keep your files on a Windows drive (for example, C:/). If you install Node.js on a Linux distribution (like Ubuntu), keep your project files in the Linux file system directory associated with the distribution that you are using. (Enter `explorer.exe .` from your WSL distribution command line to browse the directory using Windows File Explorer.)
19
+
-**Docker containers**: If you want to use Docker containers to develop your project on Windows, we recommend that you [Install Docker Desktop on Windows](https://docs.docker.com/desktop/setup/install/windows-install/). To use Docker in a Linux workspace, see [set up Docker Desktop for Windows with WSL 2](/windows/wsl/tutorials/wsl-containers) to avoid having to maintain both Linux and Windows build scripts.
17
20
18
-
## Install WSL 2
21
+
## Install Windows Subsystem for Linux
19
22
20
-
WSL 2 is the most recent version available for Windows and we recommend it for professional Node.js development workflows. To enable and install WSL 2, follow the steps in the [WSL install documentation](/windows/wsl/install-win10). These steps will include choosing a Linux distribution (for example, Ubuntu).
23
+
See the [WSL install documentation](/windows/wsl/install) if you plan to use a Linux development environment with Node.js. These steps will include choosing a Linux distribution (Ubuntu is the default) and the version of Windows Subsystem for Linux (WSL 2 is the default and recommended version). You can install multiple Linux distributions if you wish.
21
24
22
-
Once you have installed WSL 2 and a Linux distribution, open the Linux distribution (it can be found in your Windows start menu) and check the version and codename using the command: `lsb_release -dc`.
25
+
Once you have installed WSL 2 and a Linux distribution, open the Linux distribution (it can be found in your Windows Terminal list or Windows start menu) and check the version and codename using the command: `lsb_release -dc`.
23
26
24
27
We recommend updating your Linux distribution regularly, including immediately after you install, to ensure you have the most recent packages. Windows doesn't automatically handle this update. To update your distribution, use the command: `sudo apt update && sudo apt upgrade`.
25
28
26
-
## Install Windows Terminal (optional)
29
+
## Windows Terminal
27
30
28
31
Windows Terminal is an improved command line shell that allows you to run multiple tabs so that you can quickly switch between Linux command lines, Windows Command Prompt, PowerShell, Azure CLI, or whatever you prefer to use. You can also create custom key bindings (shortcut keys for opening or closing tabs, copy+paste, etc.), use the search feature, customize your terminal with themes (color schemes, font styles and sizes, background image/blur/transparency), and more. [Learn more in the Windows Terminal docs](/windows/terminal).
29
32
30
-
[Install Windows Terminal using the Microsoft Store](https://www.microsoft.com/store/apps/9n0dx20hk701): By installing via the store, updates are handled automatically.
31
-
32
33
## Install nvm, node.js, and npm
33
34
34
35
Besides choosing whether to install on Windows or WSL, there are additional choices to make when installing Node.js. We recommend using a version manager as versions change very quickly. You will likely need to switch between multiple versions of Node.js based on the needs of different projects you're working on. Node Version Manager, more commonly called nvm, is the most popular way to install multiple versions of Node.js. We will walk through the steps to install nvm and then use it to install Node.js and Node Package Manager (npm). There are [alternative version managers](#alternative-version-managers) to consider as well covered in the next section.
Copy file name to clipboardExpand all lines: hub/dev-home/setup.md
+2-4Lines changed: 2 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
---
2
2
title: Dev Home Machine Configuration
3
3
description: Set up your Windows development environment with Dev Home by using the integrated set up tool to get your machine to a development-ready state. Use the step-by-step graphical interface to walk through the setup process or use a WinGet Configuration file with pre-defined setup requirements.
4
-
ms.date: 05/07/2024
4
+
ms.date: 11/26/2024
5
5
ms.topic: overview
6
6
---
7
7
@@ -21,12 +21,10 @@ When you select **Machine configuration**, Dev Home will provide multiple set up
21
21
22
22
-**Set up a local machine**: Install applications, clone repositories, and add all of the requirements for a new development project using the built-in graphical configuration interface to enable unattended setup of your environment. The step-by-step tool will walk you through everything you need, including suggestions for popular dev tools or known repositories. At the end of the process you can generate a WinGet Configuration file to make it easy to apply these same steps to any machine. Once you've made all of your choices, sit back and let Dev Home handle the rest. If you've cloned any repositories that contain a WinGet Configuration file, Dev Home will detect that and let you continue to complete your set up.
23
23
24
-
-**Set up an environment**: *Experimental Feature*. Target an existing environment to configure by selecting applications to install and public repositories to clone in your specified development environment. From Hyper-V to Microsoft Dev Box support, Dev Home makes it easy to set up any other environment as easily as you can your local machine.
24
+
-**Set up an environment**: Create a new local or cloud environment for development. Once created you can launch it from the environments page, or select it for configuration. You can also target an existing dev environment to configure by selecting applications to install and public repositories to clone. Examples include Hyper-V (local virtual machines), Microsoft Dev Box (cloud-based dev environments)... set up any other environment as easily as you can your local machine.
25
25
26
26
-**Run a configuration file for an existing setup**: Use a [WinGet Configuration file](../package-manager/configuration/index.md) to consolidate all of your machine setup and project onboarding tasks into a single file, making the process of setting up your development environment reliable and repeatable. WinGet Configuration files use a YAML format with a JSON schema applying Windows Package Manager and PowerShell Desired State Configuration (DSC) Resource modules to handle every aspect of your machine set up. Remove any worry over finding the right software version, packages, tools, frameworks, and settings when onboarding to a new team or project. In this experience you can switch between a summary view or check out the raw contents of the YAML file. Be sure to [check the trustworthiness of a WinGet Configuration file](../package-manager/configuration/check.md) before running it.
27
27
28
-
-**Create environment**: *Experimental Feature*. Create a new local or cloud environment for development. Once created you can launch it from the environments page, or select it for configuration.
29
-
30
28
-**Clone repositories**: Once you have connected your credentials using the [Dev Home GitHub extension](extensions.md#dev-home-github-extension) or the [Dev Home Azure extension](extensions.md#dev-home-azure-extension), you can use Dev Home to clone repositories on to your machine.
31
29
32
30
-**Install applications**: Use Dev Home to discover and install software applications -- one at a time or have Dev Home install several while you take a snack break.
0 commit comments