Unhandled Promise Rejection

[daveisfera]

Bug report

What is the current behavior?
We just had a bad build deploy and after digging in, it turns out that we there was an unhandled promise rejection that didn't cause the build to fail like it should have. Here's the output:

(node:18) UnhandledPromiseRejectionWarning: Error: "." is not in the SourceMap.
    at BasicSourceMapConsumer.SourceMapConsumer_sourceContentFor [as sourceContentFor] (/usr/src/app/node_modules/source-map/lib/source-map-consumer.js:753:13)
    at /usr/src/app/web/node_modules/webpack-sources/lib/applySourceMap.js:144:46
    at SourceNode_walk [as walk] (/usr/src/app/node_modules/source-map/lib/source-node.js:230:9)
    at SourceNode_walk [as walk] (/usr/src/app/node_modules/source-map/lib/source-node.js:226:13)
    at applySourceMap (/usr/src/app/web/node_modules/webpack-sources/lib/applySourceMap.js:58:13)
    at SourceMapSource.node (/usr/src/app/web/node_modules/webpack-sources/lib/SourceMapSource.js:198:11)
    at exports.getSourceAndMap (/usr/src/app/web/node_modules/webpack-sources/lib/helpers.js:17:21)
    at SourceMapSource.sourceAndMap (/usr/src/app/web/node_modules/webpack-sources/lib/SourceMapSource.js:184:10)
    at getTaskForFile (/usr/src/app/web/node_modules/webpack/lib/SourceMapDevToolPlugin.js:77:30)
    at /usr/src/app/web/node_modules/webpack/lib/SourceMapDevToolPlugin.js:264:22
(node:18) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:18) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

If the current behavior is a bug, please provide the steps to reproduce.

This was an error that happened and re-running with the same code didn't cause the same problem, but erroring out without an indication that things went bad is very concerning and problematic.

What is the expected behavior?

The error would be raised so our build could fail rather than deploy a bad build.

Other relevant information:
webpack version: 5.0.0-rc.0
Node.js version: 12.18.4
Operating System: Debian Buster 10.5
Additional tools: babel 7.11.6

[alexander-akait]

Please create reproducible test repo otherwise issue will be closed

[alexander-akait]

Same - webpack/webpack-sources#65
Same - webpack/webpack-sources#55

Without reproducible test repo we can't help

[daveisfera]

Actually, this is reproducible, so I'm looking into isolating the cause to see if I can make a reproducer

[alexander-akait]

@daveisfera do you use typescript or babel-typescript?

[daveisfera]

We've started playing with it but don't use it yet. I've been able to isolate the bundle that's causing the problem, but any advice on isolating the cause the problem?

[alexander-akait]

Just create reproducible test repo

[daveisfera]

Yes, that's what I'm working on, but the issue only happens when terser is run because mode is set to production, so I was wondering if you had any advice on how to isolate what's causing the problem so I can make a minimal reproducer.

[alexander-akait]

@daveisfera Just create example with mode: 'production' 😄

[daveisfera]

The code that's running into this is a large/complex set of application code that I can't share, so I'd like to extract out just the problematic code and make a reproducer from that.

While playing around with things, I noticed that forcing storybook to using the more recent versions of terser and terser-webpack-plugin fixes the issue, i.e. I added the following to package.json:

"resolutions": {
  "terser": "~5.3.0",
  "terser-webpack-plugin": "~4.2.0"
},

[alexander-akait]

@daveisfera Please report the issue in terser-webpack-plugin, we can't fix it on our side, feel free to feedback

[daveisfera]

It's good that it looks like this being resolved, but honestly, my bigger concern was that this "silently failed". It killed the build but the status code was still 0, so a completely bogus build was deployed when it should have been able to be caught, so is that something that could be fixed to prevent this sort of issue in the future?

[alexander-akait]

Bug found webpack/webpack-sources#89

[ebbishop]

@daveisfera We ran into a similar problem. We were able to fix the underlying problem with the plugin, but in the mean time, the deployment went out without compiled js & css. It would have been much better to have the build fail. #12086