Bug report

In Webpack 4, the undocumented module.unsafeCache default true value can put development servers into a bad state. Changing the default in v4 would probably be a breaking change and is probably not a great solution here (the default value in v5 looks a lot more reasonable), but documenting this option would save a few headaches. I'm willing to open a documentation PR if that's the right solution.

What is the current behavior?

1. Assume webpack resolves modules from both src/ and node_modules/, in that order. Ensure that resolver.unsafeCache is off and module.unsafeCache is unset.
2. Add files src/foo.js and src/bar.js. Have src/foo.js import "bar", and add foo as an entrypoint.
3. Start webpack in watch mode.
4. Install a module at node_modules/bar/ and delete src/bar.js.
5. Get a file not found error something like this:

"ModuleBuildError: Module build failed (from /project-directoroy/node_modules/imports-loader/index.js):
Error: ENOENT: no such file or directory, open '/project-directory/src/foo.js'"

This goes away with a restart. It behaves like resolver.unsafeCache is enabled, but some debugging reveals that this is caused by the dependencyCache in the NormalModuleFactory. The default module.unsafeCache value of true is unexpected here.

What is the expected behavior?

If a file is missing, it should attempt to be re-resolved (which seems to be the default behavior for most modules in Webpack 5).

As I mentioned above, I don't think a code update is reasonable, but I do think that documenting this option and mentioning the defaults for both v4 and v5 would help people track down similar issues.

This issue follows issue #6045, which raised a bug and the need for documentation. I believe that #8277 experienced a similar issue.

Other relevant information:

webpack version: 4.43.0
Node.js version: 12.15.0
Operating System: CentOS 7