You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the most annoying issues with source maps today is that they are referenced by names. This makes working with them in production very challenging. Sentry for instance needs to download all referenced source minified files, to then try to use those minified files to locate the source map and then hope that it's there. If it's not there, we hope that the users actually managed to upload the source maps with the information of that URL to our own system (eg: they need to achieve an exact match of where the source map is supposed to be but instead of uploading them to the public place, they upload them to us with the URL as name).
This is very brittle and usually means that many people have challenges getting source maps to work reliably for their own applications.
We have much better success with debug information files from C/C++ and other languages where we get a unique build ID which can then be fetched by that ID from a symbol server.
I'm curious if there is some appetite with embedding a unique build ID into the source map and to include that ID in the error.stack for reference by other tools.
I made a similar proposal for WASM (which however uses DWARF) and there is some movement into that direction: WebAssembly/tool-conventions#133
The text was updated successfully, but these errors were encountered:
mitsuhiko
changed the title
Unique BuildIDs for Source Maps
Unique Debug IDs (Build IDs) for Source Maps
Apr 2, 2023
One of the most annoying issues with source maps today is that they are referenced by names. This makes working with them in production very challenging. Sentry for instance needs to download all referenced source minified files, to then try to use those minified files to locate the source map and then hope that it's there. If it's not there, we hope that the users actually managed to upload the source maps with the information of that URL to our own system (eg: they need to achieve an exact match of where the source map is supposed to be but instead of uploading them to the public place, they upload them to us with the URL as name).
This is very brittle and usually means that many people have challenges getting source maps to work reliably for their own applications.
We have much better success with debug information files from C/C++ and other languages where we get a unique build ID which can then be fetched by that ID from a symbol server.
I'm curious if there is some appetite with embedding a unique build ID into the source map and to include that ID in the
error.stack
for reference by other tools.I made a similar proposal for WASM (which however uses DWARF) and there is some movement into that direction: WebAssembly/tool-conventions#133
The text was updated successfully, but these errors were encountered: