serverless-heaven / serverless-webpack

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

@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?

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.

@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

@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.

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.

@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!

Released with 5.3.0

Unexpected watcher stops