Namraj Pudasaini
Jul 23, 2026
Working with Node.js inside Windows Subsystem for Linux (WSL) comes with a few pitfalls. Here are the solutions to the most common problems.
Your Windows drives are mounted under /mnt/. To access your development folder:
cd /mnt/c/Users/activ/dev/
You can set up shortcuts in ~/.bashrc for convenience:
alias home="cd /mnt/c/Users/activ/"
alias lab="cd /mnt/e/lab/"
After adding these, reload your shell:
source ~/.bashrc
If you use nvm for Windows (nvm4w), the Node and npm binaries are at a different path than the default install. Add them to your PATH in ~/.bashrc:
# nvm4w installs to c:\nvm4w, not the default c:\Program Files\nodejs
PATH=$PATH:"/c/nvm4w/nodejs"
Verify your setup:
node --version
npm --version
This is the most common issue developers hit. Vite uses file-system events to trigger hot reloads, but WSL does not always forward these events correctly — especially when your project files live on a Windows drive (/mnt/c/ or /mnt/e/).
The symptom is that changes to files do not trigger a reload in the browser.
The fix: Use polling mode by setting an environment variable:
CHOKIDAR_USEPOLLING=true npm run dev
Alternatively, if node_modules was installed by Windows npm but you are running from WSL, you may see strange errors. The cleanest fix is to reinstall dependencies from inside WSL:
rm -rf node_modules package-lock.json
npm install
npm run dev
If you are not sure which shell you are using:
echo $0
echo $SHELL
echo $0 is more accurate — it reflects the current running shell, even if you temporarily switched with bash or zsh.
Reading /mnt/c from WSL crosses a bridge between the Linux and Windows filesystems, and every file operation pays that cost. Tools that touch thousands of small files — npm install, git status, a bundler's initial scan — feel noticeably slower there than they do on Windows or on native Linux. This is the same root cause as the file-watching problem above.
Keep projects on the Linux side instead:
mkdir -p ~/projects
cd ~/projects
You do not lose access from Windows. WSL exposes the Linux filesystem under \\wsl$\, and you can open the current directory in Windows Explorer straight from your shell:
explorer.exe .
VS Code handles this well too — with the WSL extension installed, code . from inside WSL opens the folder with the editor's backend running on the Linux side.
When WSL gets into a bad state — DNS not resolving, a stuck process, or config changes that need to take effect — shut the whole VM down from PowerShell:
wsl --shutdown
The next command you run in a WSL terminal boots it again. It is much faster than rebooting Windows and fixes more than you would expect.
Rule: keep your project files inside WSL (
~/), not on a Windows drive (/mnt/c/). This avoids file-watching issues, path problems, and slow I/O.
Next steps: for general dev environment fixes (PostgreSQL, FAT32, disk space), see Dev Environment Quick Fixes.
Tools mentioned: Cloudflare Workers for edge deployment, DigitalOcean for cloud servers.