Sourcemaps in production?

1

Sourcemaps are quite useful in production, when using any sort of error reporting service (like Bugsnag). How do we enable them in production?

3 Likes
2

Has anybody been able to get something like Bugsnag or Sentry set up to track errors? The errors that come out on the frontend are useless because it’s compiled, with no source map - same for the server. Did some searching on google for “meteor source map” and other relevant terms and could not find anything.

3

Don’t people usually minify their code for the client? What suggestions does bugsnag have for this, for people who use uglify etc?

4

Yup! Minify, but provide a source map. More info here: http://blog.bugsnag.com/sourcemaps-info and towards the bottom of the JS docs: https://bugsnag.com/docs/notifiers/js. Sentry and other error tracking services provide similar features via source maps.

2 Likes
5

I don’t know what bugsnag says, but the size of the sourcemaps comment link at the bottom of a minified (uglified) multi-MB js file (hundreds of KB gzipped) is pretty trivial.

Edit: Although, does that mean we have to also ship uncompressed JS files with a production bundle?

6

I’d like to vote for this.
We’re using atatus.com which also support source maps.
The only source maps I found in the .meteor dir is of the development env.
How would I generate source maps in the meteor deploy process ?

7

This kind of died, but I still don’t understand how Meteor devs debug client-side JS errors in production - errors caught by any of the bug tracking tools/products are garbled because no source map. Might be a good topic for the Meteor guide? :slight_smile:

8 Likes
8

So is there just no way to create sourcemaps for a production build? I wouldn’t even mind if they’re not deployed, because good exception services let you upload sourcemaps from your build process. But I can’t even find that.

3 Likes
9

We know the code we write really well, so when an error occurs, we instinctively know based on obtuse error messages, what the root case is… :wink:

I’m only half-joking…

I’m all for something on the client that makes it easier to “reason” where errors come from.

10

any new information on this? Seriously, how can we debug production app errors without sourcemaps?

A new error type has occurred in White Rabbit Express.

Message: TypeError: instanceof called on an object with an invalid prototype property.

Stacktrace:

at function ()  line null, column null (null:null)
at nrWrapper line null, column null (null:null)
1 Like
11

Here’s a link to a feature request on the meteor github issue tracker for solving this problem:

3 Likes
12

This would really be a big help. Most of the bug trackers allow you to upload sourcemaps and thus quickly make sense of clientside errors when they fire.

13

I guess this will never happen since I heard there is only one development working on Meteor now–the rest have all moved to Apollo (apparently he went on vacation and the repo saw no new commits during the duration of his absence!)

2 Likes
14

Came across this issue recently. Here is a Production Source Maps For Meteor using zodern:standard-minifier-js.

2 Likes