DebugIDs in the JavaScript Ecosystem

[smeubank]

Description

Sentry and other tools like it, want to provide a feature, where when an error occurs in in JS that we can capture the associated stack trace(s), and then map those to the users source code. This is not always easy to do. There are source maps, which in the past we always required users to related to a specific release so we can properly relate the error to the source maps of that release. Since the a new approach has been developed which removes the need to match to the release. These are commonly called debugIDs. While we have added this to our own Sentry specific tooling (sentry-cli and our bundler plugins), we would like to see this solution be available across JavaScript tooling and be agnostic to tooling.

So far only Sentry and Bun, has added debugIds. We would like to see it be in bundlers by default, in browsers, and even in frameworks if possible.

Debug IDs

We have proposed a new debugId comment at the end of the source file to identified source maps by debug ID. We are however today not reading this comment due to lack of browser APIs. Instead we are relying on an injected code snippet that registers modules by URL.

Workstreams:

• To standardize debug IDs we would require a way to support browsers not providing that API (polyfill). The proposed solution is to fall back to XHR fetching and parsing of the debugId comment.
  • We would need to create confidence that this approach is possible
  • Alternatively we would need to see if alternatives can be found
• Our injection tooling does not yet assume that other people emit a debugId comment. This means that external bundlers supporting debug IDs would break functionality.
  • Make the injection process either ignore debugIDs
  • or, alternatively parse debugID comments and just do the injection of the snippet.

External Communication:

• Today we do not want to encourage bundles to emit debugID comments because we are not yet capable of processing them.

• from an internal document

Sentry Docs: What are Artifact Bundles?

Why should we be doing this?

This will make providing developers with a solution for mapping to their source code much more ubiquitously available. Ideal regardless of what tooling choices they make for their stack and even agnostic to APM and error tracking tools they choose.

Why now?

This is a problem which will not be solved over night, and as we have seen even within the microcosm of Sentry users, it is a long road to make a large impact. So time like yesterday to get going.

RFC

TC-39 Proposal: https://github.com/tc39/source-map/blob/main/proposals/debug-id.md

Slack-Channel

No response

Notion Document(s)

Notion: Source Maps DebugID Strategy

• unofficial but good context

Stakeholder(s)

Everyone

Team(s)

FE and RN

SDKs

Tooling

Beta Give feedback

1. Webpack
2. Turbopack
3. Vite
4. Rollup
5. Esbuild
6. TypeScript?
7. Babel
8. Terser
9. Deno
10. Node

Need to confirm this list, above are just some common tools for compiling, transpiling, bundling...code. Which ones are truly relevant and most important we should confirm. And we can consider similar to Bunjs to add to other server frameworks.

[timfish]

debug id usage outside of Sentry:

• Expo - https://github.com/expo/expo/blob/b8b3391718ff7829cc0211e685fd71697e47799f/packages/%40expo/metro-config/src/serializer/fork/baseJSBundle.ts#L172
• Backtrace - https://github.com/backtrace-labs/backtrace-javascript/blob/07327b3c62b6b212f4e41a519ac7469a2779e2d9/tools/cli/README.md?plain=1#L118