--watch doesn't work in latest (1.4.15) webpack on osx yosemite 10.10

[neverov]

I have a single js file entry.js with document.write("foo") line and run webpack --watch entry.js bundle.js. Webpack starts in watch mode, then I make some changes to a file and can't see the update to the bundle.

[sokra]

You can try the NewWatchingPlugin:

// webpack.config.js
var webpack = require("webpack");
module.exports = {
  plugins: [
    new webpack.NewWatchingPlugin()
  ]
};

[neverov]

Nope, doesn't work either(
Maybe I can somehow debug this issue?

[sokra]

You can run the tests here: https://github.com/webpack/watchpack
npm test

[neverov]

hm, all tests passed
ok, I'll try to reinstall everything from scratch and try again

[sokra]

So in general the watching works fine... (NewWatchingPlugin)

[neverov]

Well, still no idea why this happened, after several restarts and reinstalls of node and npm everything went back to normal. Maybe some hardware issue?

[amccloud]

I'm experiencing the same issue on OS X 10.9.5 with webpack 1.5.x.
When i downgrade to webpack 1.4.x everything works fine.

Edit: Maybe it's not the same issue but related?

[andreypopp]

I second that, webpack 1.5.x doesn't watch files properly on Mac OS X (triggers only on second or third change) while webpack 1.4.x works fine.

[neverov]

@amccloud @andreypopp should I reopen this one?

[mindjuice]

FYI, this is a bug in OS X. Try the suggestions listed in this article to fix the problem:

http://feedback.livereload.com/knowledgebase/articles/86239-os-x-fsevents-bug-may-prevent-monitoring-of-certai

Here is a copy of the meat of the article in case that link ever goes away:

Fixing it
Because we don't know the real cause of the bug, there is no surefire way to resolve it. However, one of the following actions has always helped so far:

• 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

[railsnerd]

Is it definitely the OSX bug? The fix list doesn't help

The previous checklist did seem to help after a few attempts.

[IngwiePhoenix]

1.4 is not the latest. Ingwie@Ingwies-Macbook-Pro.local ~/W/BIRD3 $ webpack --version webpack 1.8.9 I am on 10.10 myself and it works. o.o

[bbirand]

I'm using webpack 1.9.7 and I also noticed this problem. As noted above, this is likely due to a bug in OS X, and therefore won't be fixed anytime soon..

[ylg]

Occurs on 1.9.11 and OS X 10.10.3. Re-cloning the affected directory from git fixes things for a few minutes, then the problem recurs (permanently until another reclone.) No other workaround had effect, e.g., renaming the directory, rebooting.

mocha --watch, DropBox, and Google Drive are all watching this directory for changes and catching them successfully. Perhaps the mechanism webpack is relying on is broken in OS X, but other tools seem to have worked around it or just not used that particular mechanism?

[ying80]

I have the same problem. I figured out a temporary solution.
I have to move the dir once, e.g:
if your webpack watch dir is at: /Users/you/work/project1/js/src
then:
mv /Users/you/work /Users/you/work123
mv /Users/you/work123 /Users/you/work

It works for a while after the move.

[sokra]

@es128

[es128]

Seeing a lot of interesting anecdotes here, but unfortunately not much that gives me a clue what's going wrong. In some cases it does look like it might be related to switching versions of node or io.js. As such, npm rebuild should always be the first thing to try in these circumstances.

The other potential solution I'd recommend for anyone suspecting something odd/wrong with their local system is switching watch modes - try using the polling mode (which is the equivalent of what mocha's watch uses).

[es128]

@ylg @ying22 what editor are you using when you experience the issue? The description of how it works at first and then loses track of subsequent changes is reminiscent of issues I've seen in the past caused by specific editors employing complex write behaviors.

[ylg]

@es128 Occurs for me with Atom 0.210.0, SublimeText 3083, and vim 7.3 (Apple's build). Adding --watch-polling doesn't improve the situation, i.e., neither works once a dir has gone bad:

% node_modules/webpack/bin/webpack.js --watch
% node_modules/webpack/bin/webpack.js --watch --watch-polling

I typically use Z shell 5.0.6, but also tried running the watch in Bash 3.2.57. This project is using iojs 2.1.0. If you think that is a possible culprit, I could certainly check if using good old node has an effect.

[ying80]

I am using sublime 3083. It stopped working after webpack watch and text editor were left running for a few days last time. But I just got back from a weekend trip and it is fine right now.

[es128]

@ylg Sounds very strange. If you're willing to spend some time debugging, I'd be interested in the result if you were to use the example script in chokidar's repo, logging out the raw event and performing the same sorts of editing actions.

I wonder if there is something about Dropbox and/or Google Drive contributing to these issues, although that isn't something I've seen reported before.

[ylg]

I tried shutting down Dropbox and Google Drive and then making some changes; they were not caught by watch. Of course, it may be that one of those two had already permanently changed the directory, and so I'll try a new clone the next time I'm at a point without a bunch of outstanding code changes.

I tried Miller's example script for chokidar (as shown in the README at https://github.com/paulmillr/chokidar) and it reported "change [filename]" each time I saved a file.

PS If we can confirm @ying22's observation that taking weekend trips may resolve the issue, I'd prefer no fix be applied to the codebase—assuming the trips can also be taken during the week.

[ying80]

I don't have dropbox or google drive

[es128]

Lol good call @ylg.

So if chokidar by itself is correctly reporting change events under the same circumstances where webpack has trouble, then perhaps there is an issue somewhere upstream of the watch layer. Sounds like it's going to be tough to diagnose and debug though given the inconsistencies you've described.

[es128]

Btw this is the example script I was referring to for diagnostic purposes (with the raw listener uncommented): https://github.com/paulmillr/chokidar/blob/master/example.js

[ylg]

Here's an example of the output from that file running via the same version of iojs after changing a file that a normal webpack run will bundle up, but watching missed, i.e., I had a --watch running at the same time as example.js:

change /My/path/file.js
RawEvent: modified /My/path/file.js { path: '/My/path/file.js',
  event: 'modified',
  type: 'file',
  changes: { inode: true, finder: false, access: false, xattrs: false },
  flags: 70656 }

One thing of interest, though probably not importance, is that the path capitalization is not the same as reported by Z shell, e.g., chokidar reports /My/path/file.js while Z prints /My/Path/file.js, i.e., only some capitalization is kept.

[es128]

@ylg the capitalization issue may be important. Do you have the option to rename those dirs to be lowercase only and see if that has any impact on the issue? Did you specify path vs Path in the dirs/glob patterns you're watching, or did it just come out of the system with the wrong capitalization on its own?

At least, it seems we have determined at this point that chokidar is NOT missing change events and the bug causing the problem you've observed is somewhere else.

[ying80]

My top level dir was also capitalized before: "/Users/me/Work". Since the move, I have named it lowercase by accident: "/Users/me/work". And I haven't had any problems since.

But this all started with OS X 10.10.3.

[es128]

Sounds like there may be some sort of issue with inconsistent capitalization in paths, but would need someone to come up with a clear reproducible case to be able to do anything about it.

[keul]

@StephanBijzitter thanks for the info, sorry, some old comments above lead me to the wrong path.

I can confirm that the uppercare to lowecase trick worked in my environment: renaming the parent directory of the project from "/Users/keul/Projects" to "/Users/keul/projects" did the trick.
Hope this will not stop working after a while.

[dslaugh]

The problem for me was that I needed to update npm. I had an old version and as soon as I updated, it started working.

[thejoecode]

Ran into a similar issue, found this and wanted to share my solution.

File changes were being detected, it just appeared that they were not. I ran watch with progress and saw that every save / touch something was happening, just no output.
webpack --watch --progress

The issue turned out to be an incorrectly configured context. The initial start of webpack would create files, but watch failed to output changed files 95% of the time. Sometimes it would output one time and then never again. Very frustrating to diagnose.

module.exports = {
context: path.resolve('./modules'),

My solution was to remove the context, and put 'modules' in front of the path in each entry. Have not had an issue since.

In short, try the --progress flag if you think your watch is not picking up file system changes. It could just be the rebuild process is failing silently, and you need to check your config.

[pfarnach]

I was having similar issues and they were solved by updating npm.

[stelund]

@pfarnach what does "update npm" mean? From which version did you upgrade from and to what version?

Edit after I learned npm can be upgraded independently of node.

[pfarnach]

@stelund I should be more specific, I updated node from 0.12.2 to 5.7.1 using NVM (Node Version Manager), which subsequently updated my NPM from 2.7.5 to 3.6.0. (Side note: I highly recommend using NVM)

[jordizle]

Webpack uses the new NewWatchingPlugin() by default in the latest version. I had to force the old watch plugin:

plugins: [ new webpack.OldWatchingPlugin() ]

This resolved the issue for me.

[richpixel]

Switching to the 'OldWatchingPlugin' worked for me as well... I'm running OSX 10.10.5 (Yosemite)

[sgarcia-dev]

Windows 10 x64 here, also had to new webpack.OldWatchingPlugin() to get the watch service to work correctly.

[davewallace]

Windows 10 x64 here, nothing above works for me so far.

[user414]

Tried @jordizle suggestion and didn't work for me on ubuntu 14.04 LTS. This happened after a recent upgrade as it was working before. Might try downgrading some parts and see where this came from.

[chogarcia]

happening for me too on vagrant Ubuntu 14.04.4.
reloads when editing with vim but not with sublime 3

found solution here: http://andrewhfarmer.com/webpack-watch-in-vagrant-docker/

[amcdnl]

Seems in Webpack2 the OldWatchingPlugin is not there anymore. Anyone got any other hacks?

Heres my config - https://gist.github.com/amcdnl/1fefceb40d57414943e20c1b3976bb18

[nahumzs]

same problem here OldWatchingPlugin is not longer here https://github.com/webpack/webpack/pull/2604/files :/

[LasseRafn]

Any status?

[mr-nicky]

I have the same issue. (mac os - el capitan 10.11.6).
Solved by removing brackets "[]" from the path.
For example:
/Users/username/test works fine.
/Users/username/test [0] doesn't work.

[decadef20]

same issue here. --watch-poll saves my day.

[discordianfish]

I'm having the same issue on ubuntu 16.04 with 1.13.3

[SpaceK33z]

Closing this issue. If you still find a bug with watching, file it in the watchpack repo.

Note that there are known issues when your parent directory contains special characters such as brackets or parentheses. See webpack/watchpack#42 for that.

[Genovo]

in Ubuntu 16.04
Renaming file from "folder (2)" to "folder2" worked for me.