Crash with multiple targets
See original GitHub issueI have a webpack.config.js with multiple targets as described here, for building a bundle for electron-main and electron-renderer. The final export is:
module.exports = [mainConfig, rendererConfig];
If I set it to either config individually, e.g.
module.exports = mainConfig;
then it works perfectly. The output is generated in the correct directory, and Webpack prints some stats at the end.
However if I export both configs in an array, then Webpack seems to crash! This is the full output I get:
$ node_modules/.bin/webpack-cli
Starting type checking service...
$
As far as I can tell it generates the output for rendererConfig, and then just immediately exits without generating mainConfig, or printing any stats. It always generates rendererConfig irrespective of the order (I guess because they are run in parallel?).
I don’t have a minimal reproducer yet, because honestly that would be a ton of work, and it might be a lot easier if there were some way to get Webpack to actually output some logs, but I’ve tried a ton of things - I even read the source code - and it doesn’t seem to have any way to output debug logs at all! --verbose does nothing. stats: 'verbose' is useless because it crashes before printing stats. The only thing that seems to print anything at all before it crashes is --progress, which gets up to 97% normally but doesn’t print any useful errors:
$ node_modules/.bin/webpack-cli --progress
Starting type checking service...
97% [0] $
How can I debug this?
webpack version: 4.43.0 webpack-cli version: 3.3.11 Node.js version: 14.0.0 Operating System: MacOS 10.14.6
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (3 by maintainers)

Top Related StackOverflow Question
@Timmmm Could you close this issue and re-create it on the ForkTsCheckerWebpackPlugin issues?
I’m currently working on the rewrite of this plugin and better support for multiple targets is on the list to improve. It would be really nice if you could create a reproduction repository.
This issue had no activity for at least three months.
It’s subject to automatic issue closing if there is no activity in the next 15 days.