[Bug] webpack 5 updated files do not trigger rebuilds

[jquense]

• I'd be willing to submit the fix

Describe the bug

Here is a repo demostrating the issue: https://github.com/jquense/webpack-pitch-repro/tree/virtual-modules

It's a bit convoluted, but bear with me it mirrors a real use case. Basically a loader will produce a virtual file that is. If during a rebuild the file is updated it's emitted but the emitted file will not be rebuilt by webpack. The same is not true if you write out a real file.

To Reproduce

https://github.com/jquense/webpack-pitch-repro/tree/virtual-modules

run yarn start, open the page, see the text. Open index.js change the string in evil and notice web pack rebuilds but the string doesn't update.

Environment if relevant (please complete the following information):

• Webpack version 5

[jquense]

ok one issue is that https://github.com/sysgears/webpack-virtual-modules/blob/master/index.js#L65

is a Set in webpack5, that seems to fix the issue sometimes (i can only get it actually produce updated files when running the server with the debugger attached, so maybe a timing issue?)

[jquense]

More context, it's not the debugger its whether --mode development is set, or more specifically if cache: true so something is not busting the cache here

[larixer]

@jquense Yes, the new watchpack was significantly changed and someone needs to find out how to properly emit the changes with this new version.

[larixer]

It seems that Webpack 5 watch support is currently incomplete

CC @samcooke98

[jquense]

I've narrowed down the issue a bit. The core problem is that watchers are producing a map of timestamps that are missing the virtual files. basically on rebuilds this line: https://github.com/webpack/watchpack/blob/master/lib/DirectoryWatcher.js#L737 nulls out the initial mtime for the virtual file, e.g. the watcher knows about the virtual file path but (obviously) doesn't know where it is.

Basically the timestamp stays null through rebuilds which breaks the "should rebuild" check. It seems like v5 has the opposite problem from #66 in that files never get rebuilt without the timestamps.

It should be said that this is a bug in v5, the value is a FileSystemInfoEntry object not just a timestamp. That will fix the problem for rebuilds after the first one. For the first recompile the null gets stuck until another build happens, at least in my repo.

[jquense]

An alternative approach here might be to wrap the WatchFileSystem directly, fixing up the map here: https://github.com/webpack/webpack/blob/master/lib/node/NodeWatchFileSystem.js#L80 would (i think) solve the problem and avoid dealing with the craziness of watchpack

[larixer]

Yeah, I'm also looking at these getTimeInfoEntries and thinking how can we deal with them? The easiest way to deal with them would be preferable

[larixer]

We can call

              fileWatcher.directoryWatcher.setFileTime(
                modulePath,
                +time,
                false,
                false,
                'change'
              );

it fixes the timing, but its not the end of the journey, it seems

[larixer]

@jquense The fix published in webpack-virtual-modules@0.3.2