webpack --watch isn't compiling changed files

Question

I tried running webpack --watch and after editing my JS files, it doesn\'t trigger an auto-recompilation.

I\'ve tried reinstalling webpack

Answer 1

Try changing --watch to -d --watch

worked for me

Answer 2

If changing fs.inotify.max_user_watches as pointend out by César still doesn't work try to use polling instead of native watchers by creating your script as shown in the docs or running webpack with --watch --watch-poll options.

Answer 3

I have had this problem when working with WebStorm.

Disabling Settings -> System Settings -> "safe write" resolved it for me.

Found the recommendation to do so in: WebPack Troubleshooting

Answer 4

Just to add to possible solutions: I had my project folder inside a Dropbox folder, moving it out solved the problem for me. (OS X)

Answer 5

Note that if you run webpack within a virtual machine (Vagrant / Virtualbox) and you change your files on the host platform, file updates in the shared folder may not trigger inotify on Ubuntu. That will cause the changes to not be picked up by webpack.

see: Virtualbox ticket #10660

In my case, editing and saving the file on de guest (in vi) did trigger webpack. Editing it on the host (in PhpStorm, Notepad or any other application) dit NOT trigger webpack whatever I did.

I solved it by using vagrant-fsnotify.

Answer 6

FYI: it seems OS X can have a folder get corrupted and no longer send fsevents (which watchpack/chokidar/Finder uses) for itself and any child folders. I can't be sure this is what happened to you, but it was very frustrating for me and a colleague.

We were able to rename the corrupt parent folder and then watch events immediately came through as expected. See this blog post for more info: http://livereload.com/troubleshooting/os-x-fsevents-bug-may-prevent-monitoring-of-certain-folders/

The recommended fixes from the above link are:

• rebooting the computer
• checking the disk and repairing permissions via Disk Utility
• adding the folder to Spotlight privacy list (the list of folders to not index), and then removing from it, effectively forcing a reindexing
• renaming the folder, and then possibly renaming it back
• re-creating the folder and moving the old contents back into it

First two did not work for us, didn't try the Spotlight suggestion, and the re-creation did not prove necessary.

We were able to find the root problem folder by opening Finder and creating files in each successive parent folder until one showed up immediately (since Finder will get hosed by this bug as well). The root-most folder that does not update is the culprit. We just mv'd it and mv'd it back to its original name, and then the watcher worked.

No idea what causes the corruption, but I'm just glad to have a fix.