How can nodemon be made to work with WSL 2?

Question

Ever since updating from WSL 1 to WSL 2 with the Windows 10 April 2020 update (and thereafter updating Ubuntu 18 to Ubuntu 20), I have not been able to get nodemon to hot reload when there are file changes in the project's directory. When I make any changes to .js files, there's no restarting of the server or output at the terminal:

I start my Node.js server with nodemon like this:

NODE_ENV=development DEBUG='knex:*' nodemon --verbose --inspect ./server.js"

And in case its useful, here is my server.js:

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server started and listening on port ${PORT}`);
});

I am not even sure how to troubleshoot this further to get more useful information about what's going on.

Dirge

have you tried nodemon -L? – Ehrenberg

@Simperfy, you're right, it works as expected with nodemon -L, thank you. Why am I needing to use the legacy watcher? – Dirge

Added the "why" to my answer - It turns out that WSL2 doesn't fully support inotify on the Windows filesystem (being handled by the 9P filesystem protocol). – Colquitt

Answer 1

Root cause:

inotify is not fully supported in the 9P filesystem protocol on WSL2.

There are several github issues on the WSL project related to this, but perhaps the most relevant is #4739.

Possible Workarounds:

1. Try nodemon -L (a.k.a. --legacy-watch) as Simperfy suggested.
   
   

2. Try running from the default ext4 filesystem (e.g. mkdir -p $HOME/Projects/testserver). Note that a symlink to the Windows filesystem will still not work. As a bonus, the WSL ext4 filesystem will be much faster for file intensive operations like git.
   
   You can still access the source from Windows editors and tools through \\wsl$\.
   
   

3. Use Visual Studio Code with the Remote-WSL extension to edit your source on the Windows filesystem. The easiest way to do this is by navigating in WSL to your project directory and running code ..

   Visual Studio Code's WSL integration does trigger inotify for some reason.
   
   

4. Downgrade the session to WSL1 if you don't need any of the WSL2 features. I keep both WSL1 and WSL2 sessions around. The best way to do this is to create a backup of the session with wsl --export and wsl --import. You can switch the version of a WSL distro at any point with wsl --set-version.
   
   I did test this on WSL1 with a sample project under the Windows filesystem, and editing via something as basic as notepad.exe under Windows still triggered nodemon to restart.

Longer answer:

nodemon worked "out of the box" for me on WSL2 on the root (/) ext4 mount (e.g. $HOME/src/testserver).

It also worked correctly when I tried it under the default /mnt/c mount that WSL/WSL2 creates. Of course, /mnt/c is much slower under WSL2. Edit - It turns out that I was using Visual Studio Code when I attempted this. Editing from other Windows apps on the Windows filesystem did not trigger nodemon to restart.

But looking at the first line of your screenshot, I see that you are running this from /c/Users/.... I'm thinking maybe you created this (perhaps CIFS) mount to try to work around the WSL2 performance issues - It's a common workaround.

I didn't set up a CIFS mount, but I was able to reproduce your problem by mounting with (substituting your Windows username):

mkdir $HOME/mnttest
sudo mount -t drvfs 'C:' $HOME/mnttest
cd $HOME/mnttest/Users/Raj/Projects/testserver

Running nodemon from this mount failed in the same manner that you describe -- Changes to the source did not trigger a restart.

However, running with nodemon -L on this mount did trigger a restart when source files were changed.

It also may be possible to fix the problem by mounting with different options, but I'm just not sure at this point. Edit - Seems unlikely, given the bug reports on this on Github.

Also, you may want to create some exports/backups of your WSL sessions. It's too late at this point (for your previous install), but you could have run wsl.exe --export to create a backup of the Ubuntu 18.04/WSL1 filesystem before upgrading. You can also change the version of a particular distribution with wsl.exe --set-version. This could give you some better "before/after" test comparisons.

Colquitt

Very nice explanation, thank you. Just as you thought, it works as expected with nodemon --legacy-watch. Can you perhaps tell me how to fix this so the legacy watcher isn't necessary? – Dirge

I did cd $HOME/Projects/testserver and then ran nodemon without -l, but it didn't recognize file changes again. I should mention that Projects is a symlink: i.imgur.com/5gzX99G.png – Dirge

Added a few more workarounds other than --legacy-watch. – Colquitt

Also, the symlink still means that the source is on the Windows filesystem and will have the inotify problem (as you've seen). You'll have to truly be on the WSL2 ext4 filesystem to get full inotify support. – Colquitt

Again, great answer, thank you. I do want to mention that I after navigating to cd $HOME/Projects/testserver (again Projects is a symlink), and then type code . which starts VSCode with WSL:Ubuntu in the statusbar: i.imgur.com/lv9WQUa.png , File changes are still not recognized (hot reload still doesn't work). – Dirge

Do you happen to have both a /C/... and a /mnt/c/...? If so, can you try symlinking to the project in /mnt/c? – Colquitt

Also try forcing a restart of the WSL session by (save all work first, then ...) doing a wsl --shutdown from cmd or Powershell and then restarting the WSL2 session. – Colquitt

/c/Users/Raj is the default directory Windows Terminal opens to. Both /c and /mnt/c exist, but /mnt/c is empty and /c has all my WIndows files. i.imgur.com/VBhla9l.png . Additionally, hotreload doesn't work in VSCode even after doing a wsl --shutdown. Moving my projects to the Linux filesystem did resolve the issue, but it's very disappointing that inotify doesn't work if files are on the Windows filesystem. Anyway, thank you very much for your super answer. – Dirge

Thanks Raj. Wish I knew what was causing mine to work under VSCode and yours not. I thought the default mountpoint for Windows drives was /mnt/, so the fact that yours is showing up in root (/C) is the only difference that I can see. I changed my /etc/wsl.conf to move the automount point to the root, but VSCode still works in that case. Are you using /etc/wsl.conf, and if so, what are your mount options? – Colquitt

And definitely agree that this is (yet another) step backwards for WSL2. I hadn't come across the problem yet myself, but given my workflow, I'd have seen it soon, so working through this was useful to the both of us. Given this problem, the performance issues of the Windows filesystem, and the lack of network bridging in WSL2; I'm probably going to continue to use WSL1 as my main environment until and unless I need Docker support or another feature that's only available in WSL2. – Colquitt

I believe I may have changed my root to be /c instead of /mnt/c because of some previous issue with Docker. My /etc/wsl.conf looks like this paste.ee/p/7ch8o – Dirge

Thanks a lot! nodemon -L index.js works perfect. Win 10, WSL2 (Ubuntu 20) – Raspberry

Thanks a lot! nodemon --inspect -L index.js work Windows 11, WSL 2 (Debian GNU/Linux 11 (bullseye)) – Flaming

Answer 2

I am using the WSL 2 and I solved the issue by adding the following env variable: CHOKIDAR_USEPOLLING=true.

This is how looks like my nodemon command:

CHOKIDAR_USEPOLLING=true nodemon index.js

Now you can keep WSL2 instead of moving your environment to WSL1.

Argeliaargent

Doesn't that have exactly the same effect as nodemon -L or nodemon --legacy-watch which was mentioned in Simperfy's original comment (and my answer), just more to type? The environment variable could be used to turn it off in all sessions if added to a startup script, though. – Colquitt

Actually, it does work for me, while the legacy watch mode did not. – Unreeve