Incorrect file path reported when using @babel/register

[ronen]

Description

When using @babel/register, the source file path reported in the case of exceptions is missing all components between the project directory and the test file. That is, rather than reporting, say:

 /projects/my-project/test/path/to-the/test-file.js:3

Instead it reports incorrectly:

/projects/my-project/test-file.js:3

Test Source

For illustration, put this test source a few subdirectories down, in test/path/to-the/test-file.js:

import test from 'ava'
test('test-name', t => {
  "foo".bar() // throws a TypeError
})

Error Message & Stack Trace

Running ava without @babel/register works as expected, reporting:

  1 test failed

  test-name

  /projects/my-project/test/path/to-the/test-file.js:4

   3: test('test-name', t => {
   4:   "foo".bar() // throws a TypeError
   5: })

  Error thrown in test:

  TypeError {
    message: '"foo".bar is not a function',
  }

but with @babel/register required, the reporter outputs the incorrect file path:

  1 test failed

  test-name

  /projects/my-project/test-file.js:3

  Error thrown in test:

  TypeError {
    message: '"foo".bar is not a function',
  }

Config

Here's package.json in its entirety for the failing case:

{
  "ava":{
    "require": [
      "@babel/register"
    ]
  },
  "devDependencies": {
    "@babel/register": "^7.0.0-beta.55",
    "ava": "^1.0.0-beta.6"
  }
}

Command-Line Arguments

No command line arguments. Just

$ npx ava

Relevant Links

Minimal reproduction here: https://github.com/ronen/ava-filepath-issue

Environment

$ node -e "var os=require('os');console.log('Node.js ' + process.version + '\n' + os.platform() + ' ' + os.release())"
Node.js v10.7.0
darwin 17.7.0
$ npx ava --version
1.0.0-beta.6
$ npm --version
6.2.0

[iamstarkov]

ran into the same issue today

[novemberborn]

Hey @ronen, thanks for the minimal reproduction!

This seems to be an issue with @babel/register. Removing it from AVA's options fixes the problem. I've also commented out the relevant line in @babel/register that installs https://www.npmjs.com/package/source-map-support and that fixes the problem too.

Could you do me a favor and take this up with @babel/register instead? Perhaps post the link here. I'm running out of time for this weekend to follow up myself. Thanks!

(I'm closing this issue for housekeeping purposes, but let's keep the conversation going.)

[ronen]

hi @novemberborn i'm happy to report something to @babel/register, but i'm not certain what to report to them! :) i don't know what it is or isn't doing that it shouldn't or should, so i don't know how to isolate the problem/generate a minimal reproduction for them. clearly, i'm not a babel maven. (and i feel like if i reported only "it behaves weird with AVA" they'd say "well, take it up with AVA"...) any hints...?

[novemberborn]

Yea no worries. I think I need to check a few more interactions between AVA and alternative configurations of source-map-support. Plus @babel/register ends up compiling test files again, so maybe something goes weird there.

In case the double compilation is what trips up the source maps, have a look at the last section here which has a suggestion on how to stop @babel/register from compiling test files: https://github.com/avajs/ava/blob/master/docs/recipes/babel.md#compile-sources

[ronen]

@novemberborn Thanks, I followed that tip (though note tweak #1889) and that fixes the filename.

In the minimal reproduction that seems to clear everything up. But in my actual app, although the filename is fixed, the source map seems to still be having trouble: the reporter lists the last line of the file as the location of the exception, and still doesn't show the source code. Unfortunately I'm not likely to have time in the next while to pare it down to another minimal reproduction.

[novemberborn]

Aha! The problem is that the source map that AVA generates no longer contains the correct path to the original source. Should have a PR soon to fix. Thanks again for finding this and for creating the reproduction, @ronen!

[novemberborn]

@ronen see #1892.