-
-
Notifications
You must be signed in to change notification settings - Fork 32
feat(debugId): Serialize source maps with debugId, not debug_id
#134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
While this change technically does not break the public API, I think it likely makes sense to release this change in a major. What do you think @loewenheim? Are there any considerations when making a major release for this crate? |
I'll get back to you on that. |
debugId, not debug_iddebugId, not debug_id
|
@loewenheim says team consensus was we can do this in a minor |
(#3005) Align debug ID injection [with the relevant TC39 proposal](https://github.com/tc39/ecma426/blob/main/proposals/debug-id.md#debug-ids-in-source-maps) by upgrading the `sourcemap` crate to [9.3.0](https://github.com/getsentry/rust-sourcemap/releases/tag/9.3.0), which serializes the Debug ID on a sourcemap [under the `"debugId"` key, instead of the `"debug_id"` key](getsentry/rust-sourcemap#134). The crate still supports reading the `"debug_id"` key, but the `"debugId"` key takes precedence if both keys are present. These changes primarily affect the `sourcemaps inject` command, which will now place the debug ID in the `"debugId"` field rather than the `"debug_id"` field. The `sourcemaps upload` command is also affected, as sourcemaps will be rewritten with `"debugId"` rather than `"debug_id"`. Previously, rewriting preserved the key being used; if a sourcemap contained both keys, both would have been preserved after rewriting, but after these changes, we emit only `"debugId"`. For example, if a sourcemap contains only the `"debug_id"` key, the rewritten sourcemap will have that key in `"debugId"` instead; however, if a sourcemap contains both the `"debugId"` and the `"debug_id"` keys, the `"debug_id"` is completely stripped, and its value ignored. Closes #2221 Closes [CLI-44](https://linear.app/getsentry/issue/CLI-44/time-capsule-dont-open-before-nov-6-2025-emit-debugid-instead-of-debug)
…3005) Align debug ID injection [with the relevant TC39 proposal](https://github.com/tc39/ecma426/blob/main/proposals/debug-id.md#debug-ids-in-source-maps) by upgrading the `sourcemap` crate to [9.3.0](https://github.com/getsentry/rust-sourcemap/releases/tag/9.3.0), which serializes the Debug ID on a sourcemap [under the `"debugId"` key, instead of the `"debug_id"` key](getsentry/rust-sourcemap#134). The crate still supports reading the `"debug_id"` key, but the `"debugId"` key takes precedence if both keys are present. These changes primarily affect the `sourcemaps inject` command, which will now place the debug ID in the `"debugId"` field rather than the `"debug_id"` field. The `sourcemaps upload` command is also affected, as sourcemaps will be rewritten with `"debugId"` rather than `"debug_id"`. Previously, rewriting preserved the key being used; if a sourcemap contained both keys, both would have been preserved after rewriting, but after these changes, we emit only `"debugId"`. For example, if a sourcemap contains only the `"debug_id"` key, the rewritten sourcemap will have that key in `"debugId"` instead; however, if a sourcemap contains both the `"debugId"` and the `"debug_id"` keys, the `"debug_id"` is completely stripped, and its value ignored. Closes #2221 Closes [CLI-44](https://linear.app/getsentry/issue/CLI-44/time-capsule-dont-open-before-nov-6-2025-emit-debugid-instead-of-debug)
…3005) Align debug ID injection [with the relevant TC39 proposal](https://github.com/tc39/ecma426/blob/main/proposals/debug-id.md#debug-ids-in-source-maps) by upgrading the `sourcemap` crate to [9.3.0](https://github.com/getsentry/rust-sourcemap/releases/tag/9.3.0), which serializes the Debug ID on a sourcemap [under the `"debugId"` key, instead of the `"debug_id"` key](getsentry/rust-sourcemap#134). The crate still supports reading the `"debug_id"` key, but the `"debugId"` key takes precedence if both keys are present. These changes primarily affect the `sourcemaps inject` command, which will now place the debug ID in the `"debugId"` field rather than the `"debug_id"` field. The `sourcemaps upload` command is also affected, as sourcemaps will be rewritten with `"debugId"` rather than `"debug_id"`. Previously, rewriting preserved the key being used; if a sourcemap contained both keys, both would have been preserved after rewriting, but after these changes, we emit only `"debugId"`. For example, if a sourcemap contains only the `"debug_id"` key, the rewritten sourcemap will have that key in `"debugId"` instead; however, if a sourcemap contains both the `"debugId"` and the `"debug_id"` keys, the `"debug_id"` is completely stripped, and its value ignored. Closes #2221 Closes [CLI-44](https://linear.app/getsentry/issue/CLI-44/time-capsule-dont-open-before-nov-6-2025-emit-debugid-instead-of-debug)
The debug ID field on all source maps is now serialized as
debugIdrather thandebug_id.To maintain backwards-compatibility with source maps that contain a
debug_idfield, we can still read thedebug_idfield. If a source map contains adebugIdfield and adebug_idfield, thedebugIdfield takes precedence, which is a change from the old behavior.Corresponding Sentry CLI PR: getsentry/sentry-cli#3005
Closes #96
Closes CLI-240