ava overrides `source-map-support` of `babel-register`

Created on 20 Jul 2016  路  8Comments  路  Source: avajs/ava

If I transpile imported modules with babel-register, stack traces of the imported modules are not correctly reported becauseava overrides source-map-support of babel-register.

This is due to the dependency mismatch between ava and babel-register. babel-register depends on source-map-support 0.2.10 and ava depends on the version 0.4.0, making the both use the different source-map-supports so one overriding Error.prepareStackTrace.

When I bump source-map-support in babel-register (babel/babel#3571), the issue goes away.

Config

{
  "ava": {
    "require": [
      "babel-register"
    ],
    "babel": "inherit"
  ...
  }
}
bug help wanted test-environment

Most helpful comment

Any updates here?

All 8 comments

Thanks for bring this up, @jgkim!

This is kinda Babel's problem, but it's still quite unfortunate. Not sure how much we should try and work around it, or whether the answer lies with AVA having improved support for use in Babel projects (i.e. not requiring babel-register).

Leaving this open until we can find a solution.

Any updates here?

Probably related to #1584 and #1805

I think we could drop the source-map-support dependency. AVA catches all errors that it reports. We also write a source map comment to the precompiled files.

If Error.prepareStackTrace exists AVA should assume stack traces are accurate. If it does not exist, we can rewrite the call sites according to the source map when we're rewriting the stack trace. The necessary logic can be extracted from source-map-support.

This would work with @babel/register and the likes, since only one source-map-support instance would be loaded, and that instance will still rewrite stack traces for our precompiled files. This may also solve our nyc interoperability issues, provided the instrumentation takes into account any input source maps.

The downside is that printing the stack trace directly (like console.error(err.stack) or t.log(err.stack)) will result in uncorrected stack traces. This is probably fine, and we can document how to use source-map-support/register manually if necessary.

We currently have an inverse problem where @babel/register overrides AVA's source-map-support: https://github.com/avajs/ava/issues/1899#issuecomment-416204989.

Regardless I think this issue is the best long-term solution.

The downside is that printing the stack trace directly (like console.error(err.stack) or t.log(err.stack)) will result in uncorrected stack traces. This is probably fine, and we can document how to use source-map-support/register manually if necessary.

We'll have to advocate the same in case AVA is used with files that it didn't compile, so it won't know how to rewrite the call sites. It can't quite go look for source maps, since other tools may have already rewritten the call sites before AVA got a chance to.

Oh latest source-map-support supports multiple source map retrievers: https://github.com/evanw/node-source-map-support/blob/595d533512ab294ce1fdca8501ad7a243173f723/source-map-support.js#L500

So if all tools would try to install the same version, things may actually work!

Was this page helpful?
0 / 5 - 0 ratings