Undefined watcher in watch-run causes error...

[derekdon]

Might not be a ts-loader issue but I thought it might be worth linking it until I figure out the cause: zinserjan/mocha-webpack#159

[johnnyreilly]

Haven't looked into this but this may be relevant:

https://blog.johnnyreilly.com/2017/02/under-duck-afternoon-in-open-source.html

[zinserjan]

The problem is that watcher is no longer available on compiler.watchFileSystem in webpack's watch-run hook when the watch compiler was closed and restarted.

watchcompiler.close() -> watchFileSystem.close() -> watcher = null -> error

Normally the watcher will be created after the compilation is ready. The only reason why this works initially is that the NodeWatchFileSystem creates a watcher instance that is never used.

I think the best solution would be to use compiler.fileTimestamps which is always available. I logged the difference between both while running ts-loader tests and both were equal.

I'll create a PR for that.

[johnnyreilly]

Is it definitely always available? Could you confirm with the webpack team please? We're trying to avoid relying on functionality that may disappear unexpectedly. It wasn't good that that happened previously as I'm sure you can imagine!

[zinserjan]

Is it definitely always available?

It looks so. fileTimestamps is either an empty object or filled with timestamps in Compiler.js. It was added 5 years ago, so I would think this is quite stable.

But like watcher.getTimes() it's nowhere officially documented.

[johnnyreilly]

Ok thanks - it might be good to take this. I'm also interested in the implications for performance this is likely to have. Would you be able to provide any insight? Does fileTimestamps produce the same value as getTimes? Or does it contain more / less? To what extent? I'm considering the merits of having compilerOptions in there as a fallback