Ability to disable source maps or to enable them with an unintrusive Error.prepareStackTrace

[spion]

Feature proposal

Add the ability to partial disable source map support. Only jest should capture errors with a detailed trace; other libraries should get a standard trace without source maps.

Motivation

Source map support interacts badly with test timeouts:

• In a larger project add a test that attempts to serialize error.stack
• The duration of this serialization will be significant and will count towards the test time (sometimes lasting seconds)

Even if you don't attempt to serialize the stack, other libraries (such as Bluebird) might try to do it before jest gets to inspect it

Pitch

Jest already adds source map support, however, it would be nice if it tried not to interfere with other libraries. It could do that by saving the original captureTrace instruction, and doing

let originalPrpeare = Error.prepareStackTrace;
Error.prepareStackTrace = function(err, frames) { 
  if (global.jestSerializingTrace) return originalPrepare.apply(this, arguments); 
  // rough sketch
  else return require('source-maps-support').prepareTrace.apply(this, arguments);
}

export function jestGetSourcemapedStack(err) {
  global.jestSerializingTrace = true;
  try {
    return err.stack;
  } finally { 
    global.jestSerializingTrace = false;
  }
}

An step further would be to scan the logged lines for strings resembling a stack trace and map them only when logged. This however could cause some confusion.

This issue cannot be fixed in Bluebird, Q or other libraries that collect stack traces, due to memory leaks if the error objects are stored. For more info see
kriskowal/q#111

[SimenB]

I'm not sure if we want to manage sourcemap installation manually. However, if you're able to put together a PR for it, I'd be happy to take a look 🙂

I'm 👎 on an option disabling it, though - I'd rather have some precision around when we intercept prepareStackTrace

Sorta related: #6965

[spion]

To be honest I am not sure what the right solution is here. Its clear that the memory leak issue should be fixed in v8, but until that happens, I don't see a lot of options.

One super invasive option is to fully monkey patch the error constructor to force "serialization" of the stack. But instead of actually serializing the stack, save the relevant parts of the frames only to an object (should be super fast), return a dummy string, and then override the error's real stack getter to construct the stack later. But that still requires libraries such as bluebird and Q to start storing the new, non-leaky, monkey patched error objects instead of serializing the stack.

[github-actions]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.