0 reactions
Readable production browser stack traces, without Sentry.
You can finally trace production browser errors back to your private code without Sentry.
We recently released s(ource)mapped-traces:
https://github.com/mathematic-inc/smapped-traces
With smapped-traces, you can use OpenTelemetry to capture production browser errors and resolve them against your source maps on your own servers.
For background:
In production, most frontend code is obfuscated: transformed into machine-readable, but not human-readable, JavaScript and served publicly.
This makes it much harder for someone to reconstruct a company’s internal codebase. But it also creates a painful tradeoff: when something breaks in a user’s browser, the error stack trace is basically unreadable.
For contrast, during development, the code is still human-readable, so errors point directly to the right file, function, and line number. Developers can quickly find the problematic code and fix it.
That is where Sentry has historically been incredibly useful.
For us, one of the most important Sentry features was source map resolution. When an error happened in production, Sentry could take the obfuscated browser stack trace, resolve it on their servers, and show developers the original human-readable location in the codebase.
Now you do not need Sentry for that.
#dev #technology #js #programming
You can finally trace production browser errors back to your private code without Sentry.
We recently released s(ource)mapped-traces:
https://github.com/mathematic-inc/smapped-traces
With smapped-traces, you can use OpenTelemetry to capture production browser errors and resolve them against your source maps on your own servers.
For background:
In production, most frontend code is obfuscated: transformed into machine-readable, but not human-readable, JavaScript and served publicly.
This makes it much harder for someone to reconstruct a company’s internal codebase. But it also creates a painful tradeoff: when something breaks in a user’s browser, the error stack trace is basically unreadable.
For contrast, during development, the code is still human-readable, so errors point directly to the right file, function, and line number. Developers can quickly find the problematic code and fix it.
That is where Sentry has historically been incredibly useful.
For us, one of the most important Sentry features was source map resolution. When an error happened in production, Sentry could take the obfuscated browser stack trace, resolve it on their servers, and show developers the original human-readable location in the codebase.
Now you do not need Sentry for that.
#dev #technology #js #programming
| 2,000 mlx | |
| 2 | |
| 0 |