give more time to workers to finish the process

[byara]

This PR gives more time to the workers to finish before ending them.

[liangchunn]

I think... we need a better way 😛

[frvge]

@efegurkan , what do you think?

[coveralls]

Coverage decreased (-0.3%) to 86.897% when pulling 9f8edc8 on byara:master into a07e303 on trivago:master.

[efegurkan]

IMO, this is a hack that should be solved better. You should find a way to add this timeout as a flag, config etc. otherwise it will be a breaking change.

[pago]

Does a smaller number work as well? Is there any real signal that we can hook into to find out the right timeout?

[byara]

I believe getting a result with any number is not guaranteed. we can try smaller numbers though.
For a signal to hook into, I think we should use the new plugin API. The done hook would be the best choice, I presume.

[liangchunn]

This plugin is already listening to the done hook. The issue is that webpack-bundle-analyzer is set up wrongly internally, and only executing after the done hook is called.

[byara]

@pago I checked different values for the timeout and it seems it depends on the size of the stats file. I'll try to add the timeout as a flag or config.

[liangchunn]

@pago
To be honest, I think this problem is related to how webpack and webpack-bundle-analyzer interacts, and this PR will just 'work around' the issues that @byara and some other people have encountered.

From what I've seen in the source of webpack-bundle-analyzer, it defers the job of actually analyzing and emitting the stats by utilizing setImmediate(() => {}) here, and then implicitly returns.

That said, webpack actually doesn't know that there's enqueued operations, since webpack-bundle-analyzer only does the transformations after I/O operations are done, which at the same time, webpack might have already declared it's job done, and calling its done callback, and on the parallel-webpack side terminating the worker farm.

This 'hack' works because the farm termination is effectively delayed, and the underlying processes are essentially allowed to do whatever they want (and yes, probably executing the enqueued operations that webpack-bundle-analyzer has set).

10 seconds should be sufficient, but imagine a hypothetical situation where a huge stats.json cannot be parsed under 10 seconds: this issue will still persist.

I might do a little bit of research/test into this again since it's pretty interesting to me why webpack-bundle-analyzer uses setImmediate rather than a synchronous call.

[pago]

Could you add it to the schema as well?
https://github.com/trivago/parallel-webpack/blob/master/schema.json

[pago]

@byara @liangchunn Last thing I'm still wondering about is the name of the flag. timeout indicates to me that the build will stop after that time but here its used to describe a mandatory delay.
How about keep-alive-after-finish or something similar?

[byara]

@byara @liangchunn Last thing I'm still wondering about is the name of the flag. timeout indicates to me that the build will stop after that time but here its used to describe a mandatory delay.
How about keep-alive-after-finish or something similar?

absolutely right. I have no problem with that. If we cannot think of something shorter, I will make the changes according to keep-alive-after-finish.