Development tools won't watch for changes in WSL2

I'm using a development tool that should rebuild/update/etc. when the source files change, but this is not happening when running the tool in Windows Subsystem for Linux (WSL2). Why, and what can I do to fix it?

Note that there are a number of questions here on Stack Overflow with the same root issue, but each question focuses on a different development tool. This is designed to be a canonical question with a Community-wiki answer that is common to all tools. Note that some tools may have additional, tool-specific answers as well which should be posted on their own questions.

Links to tool-specific questions:

• nodemon: How can nodemon be made to work with WSL 2?
• npm run watch: npm watch suddenly stopped working on WSL
• Tailwind: Hot reload not working properly for Tailwind on WSL2
• tail -f: How do I examine the tail of a growing file on WSL-2
• webpack --watch: Running webpack with watch in Bash on Ubuntu on Windows builds once and exits
• Angular LiveReload: Angular LiveReload not working with Windows Subsystem for Linux
• React: WSL 2 , React not reloading with file changes?
• Flask: Flask does not reload modified code when running under WSL
• Next.js: Have to restart the Next.js dev server to view any changes
• Parcel Hot Module Reload: HMR not working (Parcel, Webpack 5) in WSL2/Ubuntu 22.04

The core issue is that the inotify API is not supported by the Plan 9 (9P) network filesystem used by WSL2 to access Windows drives. This impacts things like tail as well as "hot reload" features in many development tools (e.g., npm watch).

This occurs in WSL2 when:

• A Linux app is attempting to use inotify to watch for filesystem changes
• The file is located on a Windows drive being access from WSL2 as, e.g., /mnt/c/path/to/project
• A Windows process is modifying the files.

Normal workarounds:

• If possible, store your file on the Linux filesystem (e.g., ~/src/path/to/project). Sometimes this is possible, other times it's not.

• Use polling in place of inotify if the app supports it. The process/arguments for doing so will, of course, differ from tool-to-tool.

• A "traditional" suggestion in the past has been to use WSL1 if it works for your use case. However, with WSL1 having not received an update in a few years now, it's becoming harder to justify its use. Still, it remains an option. Under WSL1, inotify works on Windows drives.