Issue 1:
I'm having an issue with webpack where if I stop watching and restart, it will build just fine, but if I edit a file and save it, the incremental build fails with this error:

Uncaught TypeError: Cannot read property 'call' of undefined

Hunting it down there's a module that does not get included in the incremental change build. Best guess is the path followed to re-make the bundle file is not being followed correctly. Upon re-running (stop and start), the missing module is included.

webpack.config.js (module names changed to protect the innocent):

var webpack = require("webpack"),
path = require('path')
;

module.exports = {
entry: {
Entry1: "./app/Entry1.js",
Entry2: "./app/Entry2.js",
Entry3: "./app/Entry3.js",
Entry4: "./app/Entry4.js",
Entry5: "./app/Entry5.js",
Entry6: "./app/Entry6.js",
Entry7: "./app/Entry7.js",
Entry8: "./app/Entry8.js",
},
output: {
path: path.join(__dirname, "public/js"),
filename: "[name].bundle.js",
chunkFilename: "[id].chunk.js"
},
module: {
loaders: [
{test: /\.js$/, loader: 'jsx-loader'}
]
},
plugins: [
new webpack.optimize.CommonsChunkPlugin("shared.js")
]
};

Issue 2:
I’ve run into a fairly strange, fairly specific problem when running webpack in watch mode on OS X. When using require.context in the presence of a module with a lot of dependencies in node_modules that was symlinked using npm link, webpack seems to open a lot of file descriptors, very quickly leading to a rapid stream of dozens of errors per second coming from OS X’s FSEvents framework:

2016-04-18 11:21 node[34856] (FSEvents.framework) FSEventStreamRelease(): failed assertion 'streamRef != NULL'
2016-04-18 11:21 node[34856] (FSEvents.framework) FSEventStreamRelease(): failed assertion 'streamRef != NULL'
2016-04-18 11:21 node[34856] (FSEvents.framework) FSEventStreamCreate: _FSEventStreamCreate: ERROR: could not open kqueue
2016-04-18 11:21 node[34856] (FSEvents.framework) FSEventStreamScheduleWithRunLoop(): failed assertion 'streamRef != NULL'
2016-04-18 11:21 node[34856] (FSEvents.framework) FSEventStreamStart(): failed assertion 'streamRef != NULL'

This issue is similar to #1743, but I am not sure that it is actually the same, since that appears to be resolved with a chokidar fix, but I am using the latest version of chokidar and still get the error.

Steps to reproduce

Since this is such a specific problem, I’ve managed to reduce it to a pretty tiny, reproducible example, which you can find at lexi-lambda/webpack-fsevents-bug. Here’s some information about my environment as well:

operating system: OS X 10.11.3

node version: v5.10.1

npm version: 3.8.3

Here’s how to reproduce the issue:

Clone https://github.com/lexi-lambda/webpack-fsevents-bug somewhere.

Enter the linking-test directory and run npm install, then npm link.

Enter the main directory and run npm install, then npm link linking-test.

Run npm run watch.

After a few seconds, you should start seeing the FSEvents errors.

More details

The issue seems to specifically be related to how running webpack in watch mode interacts with require.context. If you look in the single module in the whole project, you’ll see the following two lines:

var context = require.context('..', false, /config\.json$/);
console.log(context.keys());

I’ve explicitly passed false to require.context, but for some reason the placement of the linked package in the node_modules subdirectory clearly affects how webpack handles this context. The error does not occur without the custom context.

I have no idea if this has anything to do with a symlinked module specifically, and it’s certainly not that simple, because it doesn’t happen if the symlinked module does not have very many dependencies. However, with a lot of dependencies, like the ones I’ve included in my sample repo, it consistently fails. It might just be caused by having a lot of files/subdirectories and have nothing to do with the symlinking—I don’t know.

Either way, this is a pretty hard failure that is consistently reproducible, even on different machines, and I’ve been running into it repeatedly with a particular project I’m working on. Thank you for making webpack, it’s a wonderful tool! And let me know if there’s any more information I can provide to help.