Feature request

What is the expected behavior?
Analyzing JS stack traces is complex. Source maps provide a reasonable debugging experience at runtime, but when analyzing an exception, it's difficult to reconstruct an unminified stack trace, even with V3 source maps available. The best case of this often is that the token at the point of the error can be discovered, so a language parser will need to walk backward from that token to try to find a function declaration to get the name.

Consider a tiny example such as this:

function causeError() {
  throw new Error('Expected failure.');
}
causeError();

Upon minification, this might become:

(()=>{throw new Error('Expected failure.')})();

A plain rendering of this in an error stack might look like:

Error: Expected failure.
    at example.js:1:13
    at example.js:1:45

With source maps, we can get a pretty reasonable output:

Error: Expected failure.
    at example-src.js:2:3
    at example-src.js:4:1

However, the token at 2:3 is throw. That isn't terribly useful. If I reconstructed that stack by hand, I would expect:

Error: Expected failure.
    at causeError (example-src.js:2:3)
    at Global code (example-src.js:4:1)

To that end, the Edge DevTools team are proposing a v4 of Source Maps that will support this by encoding a notion of "scopes" -- source text ranges that correspond to a given runtime name. This is at MicrosoftEdge/MSEdgeExplainers#538.

What is motivation or use case for adding/changing the behavior?
We've seen other tools that do this -- https://github.com/bloomberg/pasta-sourcemaps as an example -- but if we can standardize this, we can incorporate that functionality into our everyday developer tools.

How should this be implemented in your opinion?
The spec proposes that the scopes field would be comprised of a list 6 VLQs for each scope name mapping:

• Source index
• Start line
• Start column
• End line
• End column
• Scope name index

Given an input source map from a tool like TypeScript already producing these values, the only thing a tool like Webpack would need to do is combine all of them, in this case, combining and de-duping the scopeNames field, and providing a small amount of modification (updating the source index and scope name index) when combining all of the various scopes values from each of the input source maps.

Are you willing to work on this yourself?
Yes. And, I've been working on producing this in TypeScript as well -- microsoft/TypeScript#47152