Insert debug-ids into sourcemaps to improve Sentry's observability

Alexey Antipov, on his very own blog: > Code errors reported to an observability service (e.g. Sentry, Datadog) contain stack traces with a chain of functions calls which lead to the exception. This information includes function name, file name and place in the file where the function is called. That should help developers in debugging their code - locate the problematic code faster. > When dealing with source maps, the hurdle lies in association of minified [filename].js files with their [filename].js.map source maps > Sentry has come up with a really neat and elegant solution to the above problems. Instead of generating releases and assigning them when uploading source-maps and initialising the application, one simply includes an additional post-bundling step - running the command `sentry-cli sourcemaps inject ./dist` which will generate a unique debug-id identifier to each script in the output ./dist > With that, every stack frame will include debug-id in addition to function name, filename, and location I've found myself using Sentry's service recently to debug some errors users were reporting on Notion to Calendar. The results were astonishing since there were many errors which were impossible to debug locally but very easy to notice with Sentry's Replay feature. Having the sourcemaps properly mapped would have been very useful though. I was not able to map next.js' sourcemaps after build to the Sentry notification script, but I will try again and make sure to follow Alexey's advice, so I can properly know if the error belongs to the last release, or not.