• --display-error-details give you more details.
• ReadConfiguration regarding resolving starting atresolve
• loaders have their own resolving configurationresolveLoader

The node.js module-resolving algorithm is pretty simple: module dependencies are looked up innode_modules folders in every parent directory of the requiring module. When younpm link modules with peer dependencies that are not in your root directory, modules can no longer be found. (You probably want to considerpeerDependencies withnpm link as broken by design in node.js.) Note that a dependency to the application (even if this is not the perfect design) is also a kind of peer dependency even if it's not listed as such in the module'spackage.json.

But you can easily work around that in webpack: add thenode_modules folder of your application to the resolve paths. There are two config options for this:resolve.fallback andresolveLoader.fallback.

Here is a config example:

module.exports={resolve:{fallback:path.join(__dirname,"node_modules")},resolveLoader:{fallback:path.join(__dirname,"node_modules")}};

Verify that webpack is not being notified of changes by running with the --progress flag. If progress shows on save but no files are output, it is likely a configuration issue, not a file watching issue.

webpack --watch --progress

Verify that if you have enough available watchers in your system. If this value is too low, the file watcher in Webpack won't recognize the changes:

cat /proc/sys/fs/inotify/max_user_watches

Arch users, addfs.inotify.max_user_watches=524288 to/etc/sysctl.d/99-sysctl.conf and then executesysctl --system. Ubuntu users (and possibly others):echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p.

On macOS folders can get corrupted. See this article:

OS X FSEvents bug may prevent monitoring of certain folders

webpack expects absolute paths for many config options.__dirname + "/app/folder" is wrong, because windows uses\ as path separator. This breaks some stuff.

Use the correct separators. I.e.path.resolve(__dirname, "app/folder") orpath.join(__dirname, "app", "folder").

On some machines Vim is preconfigured with thebackupcopy option set toauto. This could potentially cause problems with the system's file watching mechanism. Switching this option toyes will make sure a copy of the file is made and the original one overwritten on save.

:set backupcopy=yes

When using the JetBrains WebStorm IDE, you may find that saving changed files does not trigger the watcher as you might expect. Try disabling thesafe write option in the settings, which determines whether files are saved to a temporary location first before the originals are overwritten: uncheckFile > Settings... > System Settings > Use "safe write" (save changes to a temporary file first).