Hi! I’m evaluating JS error tracking tools like Sentry for my company’s Front-end team. It seems to have pretty robust Sourcemap support.
What I’m writing to find out is whether or not Sentry supports multi-level sourcemaps specifically. Our main front-end tool has two separate builds with their own sets of sourcemaps. Then a final build combines the output from these two build, producing a final set of sourcemaps which still map to the original source files.
This multi build process is gonna be around for at least another year and a half, so not having this support would be a deal-breaker for us.
Hey, I’m not super familiar with what this even means, so can you provide an example? And is this a thing that’s supported in browsers? I’m pretty sure we won’t crawl and map sourcemaps of sourcemaps together, but I’d have to re-read the code and see if it just would magically work, but I’m pretty sure it wouldn’t.
Yeah, I hear yeah. I didn’t even know this was a thing until recently either, because it does just magically work in modern browsers, and has been supported in the sourcemap spec for a while. Here’s an article talking about about multi-level sourcemaps, which are most commonly used for doing things like precompiling coffeescript. The only reason I bring it up is because Rollbar, the tool we are using currently, does not support this functionality yet (Though they say they will eventually). It’s a big reason we are looking for an alternative.
At the very end of Rollbar’s docs on source map usage, the last bullet point on debugging, they reference not supporting this: https://rollbar.com/docs/source-maps/
If I’m reading this correctly, my understanding is that “multi-level” source maps merely refers to generating a single source map using multiple build steps, i.e. CoffeeScript => Uglify => final minified JS (2 steps). It still produces a single source map file that should map your final code to your original source code.
In which case, Sentry should support this. Ultimately we use the source map to just match your production files/lines/columns back to their original locations. How they are built doesn’t really matter, as long as they correctly have this mapping.
–
At the very end of Rollbar’s docs on source map usage, the last bullet point on debugging, they reference not supporting this: https://rollbar.com/docs/source-maps/2
Are you referring to this?
Some source map generation tools support an alternate representation of the map that combines multiple sub-maps into “sections” within the top level map. Each section can either be embedded source map or a reference to an external source map. Unfortunately, we don’t yet support this source map format.
These are called “indexed” source maps, and Sentry does support them (!). I don’t think this is what you’re referring to, though. But they are generated by some build tools, i.e. the React Native bundler, and are interpreted correctly by Sentry.
Thanks so much for the reply! The inner workings of source maps are still fairly new to me, so I appreciate the clarification. This is great news. Our team will be digging deeper into Sentry for sure.
Hi
I’ve same issue . In our project we’re doing browserify & uglify for combining and minification of js files
broweserify >> site.js (it has own sourcemap ,at the end of this file //# sourceMappingURL=data:application/json;base64 …)
uglify site.js >> site.min.js
we’re using site.min.js for our project . So is it possible capture at second level means not in site.js line but in actual file from where site.js created