Summary
The main dev-config.winget installs NVM for Windows (CoreyButler.NVMforWindows), which manages Node.js versions via a symlink at C:\nvm4w\nodejs and adds that to PATH. However, the TypeScript workload (Workloads/typescript/configuration.winget) separately installs OpenJS.NodeJS.LTS directly via winget, which places Node at C:\Program Files\nodejs.
This creates a broken state where:
- PATH points to
C:\nvm4w\nodejs (set by nvm4w)
- The nvm4w symlink targets a version directory (e.g.
C:\Users\<user>\AppData\Local\nvm\v24.16.0) that does not exist because Node was installed via the MSI package, not through nvm install
node and npm are not found on PATH despite Node.js being physically installed
Steps to Reproduce
- Apply the main
windows-dev-config/dev-config.winget (installs nvm4w, adds C:\nvm4w\nodejs to PATH)
- Apply
Workloads/typescript/configuration.winget (installs OpenJS.NodeJS.LTS to C:\Program Files\nodejs)
- Open a new terminal
- Run
node --version → command not found
Root Cause
nvm4w owns the PATH entry (C:\nvm4w\nodejs) and expects Node to be installed via nvm install <version> + nvm use <version>. The direct winget install of OpenJS.NodeJS.LTS puts node elsewhere and nvm4w's symlink points to a non-existent directory.
Suggested Fix
Option A — TypeScript workload defers to nvm4w:
Replace the OpenJS.NodeJS.LTS winget package resource with a RunCommandOnSet that runs:
nvm install lts
nvm use lts
Option B — Remove nvm4w from dev-config, let workloads install Node directly:
Remove CoreyButler.NVMforWindows from dev-config.winget and ensure C:\Program Files\nodejs ends up on PATH (the Node MSI installer does this by default).
Option C — Keep both but coordinate PATH:
If both are intentional, the TypeScript workload should add C:\Program Files\nodejs to PATH explicitly, or the refresh-path.ps1 should detect and resolve the nvm4w symlink conflict.
Environment
- Windows 11 (Build 2026)
- winget v1.28.240
- CoreyButler.NVMforWindows 1.2.2
- OpenJS.NodeJS.22 24.16.0 (installed by winget as the LTS package)
Summary
The main
dev-config.wingetinstalls NVM for Windows (CoreyButler.NVMforWindows), which manages Node.js versions via a symlink atC:\nvm4w\nodejsand adds that to PATH. However, the TypeScript workload (Workloads/typescript/configuration.winget) separately installsOpenJS.NodeJS.LTSdirectly via winget, which places Node atC:\Program Files\nodejs.This creates a broken state where:
C:\nvm4w\nodejs(set by nvm4w)C:\Users\<user>\AppData\Local\nvm\v24.16.0) that does not exist because Node was installed via the MSI package, not throughnvm installnodeandnpmare not found on PATH despite Node.js being physically installedSteps to Reproduce
windows-dev-config/dev-config.winget(installs nvm4w, addsC:\nvm4w\nodejsto PATH)Workloads/typescript/configuration.winget(installsOpenJS.NodeJS.LTStoC:\Program Files\nodejs)node --version→ command not foundRoot Cause
nvm4w owns the PATH entry (
C:\nvm4w\nodejs) and expects Node to be installed vianvm install <version>+nvm use <version>. The direct winget install ofOpenJS.NodeJS.LTSputs node elsewhere and nvm4w's symlink points to a non-existent directory.Suggested Fix
Option A — TypeScript workload defers to nvm4w:
Replace the
OpenJS.NodeJS.LTSwinget package resource with aRunCommandOnSetthat runs:Option B — Remove nvm4w from dev-config, let workloads install Node directly:
Remove
CoreyButler.NVMforWindowsfromdev-config.wingetand ensureC:\Program Files\nodejsends up on PATH (the Node MSI installer does this by default).Option C — Keep both but coordinate PATH:
If both are intentional, the TypeScript workload should add
C:\Program Files\nodejsto PATH explicitly, or therefresh-path.ps1should detect and resolve the nvm4w symlink conflict.Environment