Unexpected watcher stops

[deftomat]

We are using fork-ts-checker-webpack-plugin to run TypeScript checks in watch mode.

This plugin starts TypeScript in watch mode in a separate process. It needs to know, when user stops the webpack's watcher to be able to stop TypeScript service. So, it is listening to watchClose hook.

However, #319 introduce a watcher stop/start after each recompilation. This leads to killing the TS service and starting it again. See https://github.com/Realytics/fork-ts-checker-webpack-plugin/blob/5f5d967e07c7da0e860b6854857da145c33c7c0f/src/index.ts#L296.

The problem is, that type-check can easily took 5-6 seconds for the first run and less than 200ms after recompilation. However, this stop/start behavior causes that it always starts from scratch.

So, my question is: Are we able to avoid stoping the watcher? I'm pretty sure that other webpack plugins can depend on it too. Also, fork-ts-checker-webpack-plugin is basically a standard for TS projects.

EDIT:
Another issue is that sometimes recompilation occurs twice:

@dwelch2344, @HyperBrain

[mochja]

@deftomat we are not using fork-ts-checker-webpack-plugin, but with Webpack 4 and ts-loader rebuild is triggered twice for me each time I change something.

Serverless: Offline listening on http://localhost:3000
Time: 3848ms
Built at: 2019-02-20 14:36:05
         Asset      Size   Chunks             Chunk Names
    handler.js  4.08 MiB  handler  [emitted]  handler
handler.js.map  4.26 MiB  handler  [emitted]  handler
Entrypoint handler = handler.js handler.js.map
[0] multi ./handler.ts 28 bytes {handler}
[./app.config.ts] 315 bytes {handler}
[./handler.ts] 3.87 KiB {handler}
    + 762 hidden modules
Time: 2727ms
Built at: 2019-02-20 14:36:07
         Asset      Size   Chunks             Chunk Names
    handler.js  4.08 MiB  handler  [emitted]  handler
handler.js.map  4.26 MiB  handler  [emitted]  handler
Entrypoint handler = handler.js handler.js.map
[0] multi ./handler.ts 28 bytes {handler}
[./app.config.ts] 315 bytes {handler} [built]
[./handler.ts] 3.87 KiB {handler} [built]
    + 762 hidden modules
Serverless: Watching for changes...
Serverless: Watching for changes...

did you happen to find solution for that?

[mochja]

I think this is related to webpack/webpack#4991.

serverless-webpack/lib/wpwatch.js

Line 37 in ffc70bc

const watcher = compiler.watch(watchOptions, (err, stats) => {

compiler.watch is triggering build first and then it's waiting for changes. So each time startWatch is exectuted, build it triggered first.

[deftomat]

@mochja Hi, we are using a custom fork as it looks like the project is not maintained anymore.

This is a commit which fixed it for us: deftomat@839d2e5

[livingmine]

@mochja @deftomat rebuild also triggered twice on my project. One thing i notice is that this line on wpwatch.js is never true

if (stats && stats.hash === lastHash) {

stats.hash and lastHash is always different. On a normal working project where this problem does not occur, that expression should be evaluated to true and acts as a terminal point of our watcher while it is waiting for the next changes.

On a troubled project however, it is as if there is another source of changes triggering the another new process which i'm still looking for.

[mochja]

We have stopped using webpack for development and instead use ts directly.

node -r dotenv/config -r ts-node/register/transpile-only -r tsconfig-paths/register node_modules/serverless/bin/serverless offline

I did spend some time in debugger and there was no additional trigger in our case.

[livingmine]

@mochja Awesome! I'm actually okay with the current situation(rebuild triggered twice) as my current build process is still less than <10s but as my project grows in size i'll keep looking for the solution and might resort to your suggestion or @deftomat fork of this repo as a last resort. Thanks!

[HyperBrain]

Released with 5.3.0