Stack traces with sourcemap support

help
1

Hi. I’m trying to tidy up reporting of javascript errors. The stack trace returned within meteor does not process the error trace with a sourcemap if it is present. (I know the dev tools console does show this but would like to have the processed version available within the application for error reporting). As meteor compresses everything into a bundle, this stack trace is often meaningless without the sourcemap lookup.

Idealy, I would like a function/method that would take the unprocessed stack trace, load the relevant sourcemap and return the prettified stack trace.

Has anyone already tackled this problem and if so, could they share their solution?

I am aware that I maybe don’t want to do this in production as anyone can see the code, but as this is an intranet app, this is not a particular concern.

2

I have seen a couple of issues related to this. Try a search on the Meteor GitHub repository.

3

Had a look but impossible to find anything. Stack trace or source map turn up many many issues and I can’t think of anything more specific to search for.

4

Let us know if you find something, for I think this would be instrumental for fixing errors. As of right now, stack traces are obviously unusable in production. Error handling is usually the orphaned child in most applications, as if it was something lowly und unpleasant, so it doesn’t receive due attention. It seems to be the case in Meteor too.

5

Would love to get support for this.

I found this

Looks like some interesting stuff in there. I’ll try some stuff and edit my post if I come up with anything.

On Meteor 2.3.5
babel-compiler@7.7.0
babel-runtime@1.5.0
Hmm, on the client, in isDevelopment mode, inside componentDidCatch, I tried checking Error.prepareStackTrace, but it’s undefined.

If I look in the browser’s dev tools manually, it shows a proper source-mapped stack trace.
But when I try to read the error object in JS as above, the filenames and line numbers are not human readable source mapped, etc.

1 Like
6

I’ll second that. It’s pain in Production and using Electron isn’t making it any easier for us.

1 Like
7

I’d love to see some movement on this.
Before I found this thread, I tried sourcemapped-stacktrace - npm but it achieves absolutely nothing.

Is there a way to use

in the browser, somehow?

Can the server clean up client error stack traces?
Or maybe the client can send it’s stack trace to the server via a method, and the server source maps it and then logs the error?
I considered this, but looking at all of the functions offered by import('source-map-support').then( allFuncsObject none of them seem to let you give them a stack trace string/array and then will make it readable. But I’m not sure about that. Did I miss something?
I did see it has a function where you can give it an error and it’ll give you back something, in theory. I tried it on the client, it just returned null. Problem is if I wanted to do this on the server, I’d have to somehow get a reference to the install’ed ‘source-map-support’ (or maybe make another one with the meteor code above) and then also would need to somehow re-create the client’s error object, by making a new error object on the server then overwriting it’s stack string (if that’s even possible)
As you can see it’s a rather crazy idea. So I’m out of ideas.

1 Like
8

I tried npm i --save source-map-support
and then I tried this (on the client)

const stack = [];

// Add a function to locate source maps; all of the functions are executed in
// reverse order
export function push(func) {
  stack.push(func);
}

function tryAllSourceMapRetrievers(filename) {
  for (let i = stack.length - 1; i >= 0; i--) {
    const sourceMapData = stack[i](filename);

    if (sourceMapData) {
      return sourceMapData;
    }
  }

  return null;
}

function wrapCallSite(unwrappedFrame) {
  const frame = sourceMapSupport.wrapCallSite(unwrappedFrame);
  function wrapGetter(name) {
    const origGetter = frame[name];
    frame[name] = function(arg) {
      // replace a custom location domain that we set for better UX in Chrome
      // DevTools (separate domain group) in source maps.
      const source = origGetter(arg);
      if (!source) {
        return source;
      }
      return source.replace(/(^|\()meteor:\/\/..app\//, '$1');
    };
  }
  wrapGetter('getScriptNameOrSourceURL');
  wrapGetter('getEvalOrigin');

  return frame;
}

const oldErr = new Error('old');
import('source-map-support').then( ({install}) => {
  install({
    retrieveSourceMap: tryAllSourceMapRetrievers,
    // Disable the feature of source-map-support that shows an accurate snippet
    // of source code on uncaught exception, because we haven't fixed it to
    // be able to locate the proper source code to display.  (Note that the
    // stack trace of an uncaught exception will be correctly source-mapped
    // independent of this option.)
    handleUncaughtExceptions: false,
    wrapCallSite
  });
  console.log("oldErr.stack", oldErr.stack)
  const newErr = new Error('new');
  console.log("newErr.stack", newErr.stack)
  console.log(Error.prepareStackTrace); // interestingly this exists now, but I have no idea if it's useful or what to do with it.
});

Doesn’t improve the human readability of the stack trace.

1 Like