Debug ID: Considering splitting the proposal

[szuend]

The Debug ID proposal consists of 3 additions:

1. The "debugId" field in the source map JSON
2. The "debugId" magic comment in bundles
3. A runtime API to get the Debug ID of the currently running script as well as the debug id of each stack frame in a stack trace.

It might be worth it to consider landing 1) and 2) independent of 3).

Why?

In Chrome DevTools we recently landed an extension API that allows extensions to attach source mapping URLs to Resources. Or provide full source maps in the form of data URLs.

With 1) and 2) in-place, DevTools could add the "debugID" as reported by the engine on the "Resource" object and extensions could use that to then resolve/load the correct source map. The current proposal already goes in a similar direction in the section "Symbol Server Support".

My question from the DevTools sides are:

1. Does this solve an actual user problem?
2. Do we have implementors of symbol/artifact servers that would want this?

cc: @lforst @robpaveza

[lforst]

That's actually a pretty cool use case being able to view/debug the original source for production code via symbol servers without having to expose the sourcemaps somewhere.

Re the questions:

1. Looking a bit into the future, I believe it would solve an actual user problem because browser extension vendors using this API would pretty much immediately run into the same struggles as we do for source mapping URLs today. URLs are extremely flakey¹ for source map association, meaning that effectively every extension vendor/company (assuming it's mostly gonna be internal tools) will have to custom tailor their symbol servers to their specific setup/infrastructure, in addition to them probably constantly breaking due to infrastructure changes that aren't aligned with the extension. Having Debug IDs available to this API would allow for a solution that is "immune" to this flakiness.

2. I can only speak for Sentry right now, where I would say no, however, it would allow for the emergence of tooling that facilitates production debugging.

Footnotes

1. Factors contributing to flakiness are things like the location of bundles changing with infrastructure changes - think CDN URLs or reverse proxies that may change independently from the logic inside the extensions attaching source mapping URLs to Resources. From experience, setups can get quite complex. ↩