Replies: 11 comments
|
Hmm but what if only some part was unsuccessful but the output still contains valid bundles? Is there a hybrid scenario possible where only some part of the webpack build failed but |
|
At least in my case, when my build fails no files are generated at all. And since I clear my dist folder before each build, I get those messages I mentioned: And at the end: Maybe we have another problem, I mean why is this plugin trying to analyze those non existing files in the first place? |
|
It is because the webpack stats object generated by webpack lists the bundles that would be output and |
|
We can probably do nothing if there are compilation errors? @valscion what do you think? |
Yeah, that might make sense. It's likely that we won't be able to do much with the resulting bundles (if there are any) after compilation errors anyway. |
|
Yeah, doing nothing after any errors (including errors resulting from multiconfigs) would be nice. Of course this also could be a configuration setting, so if users want to have a report even after having errors, they still can do that. But I think in most cases, it makes no sense to generate a report when the build fails anyways. |
|
Nah, I'd prefer not adding new configuration options for this |
|
OK, I also would be fine with no additional options |
|
This still appears to be an issue. |
|
Same here, it's incredibly annoying to see By default it should just detect the failure and output just "Webpack failed, no soup for you!", especially when it cannot find the assets at all and it shows: |
|
PR welcome :) |
Uh oh!
There was an error while loading. Please reload this page.
Right now, when my build fails the bundle analyzer runs nonetheless, spitting out hundreds of lines like "Error parsing bundle asset ..."
It would be much nicer if I could configure this plugin to run only after a successful build
All reactions