babel-register support

[edongashi]

Hi, I tried using this tool with babel-register, but the source lines are coming back incorrectly. I tried using both values for sourcemap property with the same weird results. Any idea how to get this to work? Thanks.

Note: new Error().stack displays the correct lines/cols even with babel-register. I think that's because babel patches stacks.

[edongashi]

After some tedious debugging I noticed that source-map and source-map-support modules are being duplicated locally to node_modules inside babel-register. One of them seems to cache stuff in memory. Looks like I need to do some ugly requires to get around this.

[watson]

@edongashi Thanks for opening this issue. Did you ever find a solution?

[edongashi]

Hey @watson, I needed to get the source code line where a method is called (the code is compiled on the fly by babel-register). The following code demonstrates how I did it:

// If babel-register uses a local module then we need to resolve to that same instance.
const { wrapCallSite } = require('babel-register/node_modules/source-map-support')

// We pass sourcemap: false because we are doing that ourselves.
stackman.callsites(myError, { sourcemap: false }, (error, callsites) => {
  if (error) {
    // handle error
  }

  const site = callsites[1]
  // Note that wrappedSite is not a stackman wrapper.
  const wrappedSite = wrapCallSite(myError.__error_callsites[1])

  // We need this because sourceContext uses .isNode
  wrappedSite.isNode = site.isNode
  // Call sourceContext but with this=wrappedSite
  site.sourceContext.call(wrappedSite, 1, (error, result) => {
    // Now we have access to the correct source line.
  })
})

To utilize any other stackman feature I guess you need to try calling that method and patching the wrapped site until all errors are removed.

The reason for all this is because babel-register initializes source-map-support with some configurations, and if there is a duplicate module it will not be aware of that.

[watson]

If I understand you correctly, the issue is that the filenames and line numbers returned by the callsite functions does not match what's in the err.stack string when you set sourcemap: false?

[edongashi]

I think sourcemap true or false does not make any difference. File names were correct but line numbers were different due to transpilation.

The problem lies here:

require('source-map-support') !== require('babel-register/node_modules/source-map-support')

The first one returns an invalid result, while the second one returns correctly mapped sites.

In this line you can see that babel-register initializes source-map-support https://github.com/babel/babel/blob/master/packages/babel-register/src/node.js#L16

In particular, retrieveSourceMap returns a patched source file. Because my stackman module was using a different instance of source-map-support, it was not initialized by babel-register to retrieve the correct source line.

It depends on the module version locking though, if there is a version incompatibility it will result in duplicate modules, others may have different results depending on their package config.

[edongashi]

Just noticed that stackman does not depend on that module, it must have been one of those source-map-* things down the graph that was causing a version conflict.

[watson]

Can you check one of the callsites that should have a sourcemap associated with it if it have a .sourcemap property?

[edongashi]

Here is an example that demonstrates this behavior:

const stackman = require('stackman')();

function MyComponent() {
  return (
    <div>
      This JSX will cause transpilation.
      <div style={{ color: 'red', margin: '20px' }}>
        Test
      </div>
    </div>
  )
}

// Error is on line 15
printError(new Error());

function printError(error) {
  stackman.callsites(error, { sourcemap: true }, (err, sites) => {
    console.log('=== sourcemap: true ===');
    console.log('Does site[0] have sourcemaps? ' + ('sourcemap' in sites[0]));
    console.log('What line is site[0]? ' + sites[0].getLineNumber());
  })

  stackman.callsites(error, { sourcemap: false }, (err, sites) => {
    console.log('=== sourcemap: false ===');
    console.log('Does site[0] have sourcemaps? ' + ('sourcemap' in sites[0]));
    console.log('What line is site[0]? ' + sites[0].getLineNumber());
  })
}

Output from running this with babel-register:

$ node index
=== sourcemap: false ===
Does site[0] have sourcemaps? false
What line is site[0]? 17
=== sourcemap: true ===
Does site[0] have sourcemaps? false
What line is site[0]? 17

The returned line is incorrect. This is the babelrc file:

{
  "presets": [ "react" ],
  "plugins": [ "transform-class-properties" ]
}

Setting "sourceMaps": true or "sourceMaps": "inline" in babelrc makes no difference.

Calling console.log(error.stack) before or after callsites prints out the correct stack trace. I had searched the babel and source-map-support code and found that one of those (forgot which) patches the prepareStack event to use wrapCallSite for each frame.

[watson]

Can you confirm that your transpiled source-file contains a sourceMappingURL comment in the bottom?

[edongashi]

I have no idea how to access the generated code. babel-register compiles in memory when you call require. I'll check if I can find that somehow.

[watson]

Ah, I just realized that this was transpiled on the fly in memory - I missed that before, sorry. I think that's the issue. I assume that it will not generate a sourcemap in that case, and as such there's no way for us to get the correct line numbers. This module does not parse the stack trace string returned by err.stack, rather it integrates deeper into V8 and accesses the internal callsites. So even if babel patches the .stack property to return a correct stack trace we'll not see it.

[watson]

To verify this hypophysis, could you try to generate a transpiled file with a source map and see if it works then?

[edongashi]

Yep, I had figured that out. The above code can be fixed by calling wrapCallSite manually. I added the require on the same line to align with previous demo:

const stackman = require('stackman')(); const { wrapCallSite } = require('source-map-support')

function MyComponent() {
  return (
    <div>
      This JSX will cause transpilation.
      <div style={{ color: 'red', margin: '20px' }}>
        Test
      </div>
    </div>
  )
}

// Error is on line 15
printError(new Error());

function printError(error) {
  stackman.callsites(error, { sourcemap: true }, (err, sites) => {
    console.log('=== sourcemap: true ===');
    console.log('Does site[0] have sourcemaps? ' + ('sourcemap' in sites[0]));
    console.log('What line is site[0]? ' + wrapCallSite(sites[0]).getLineNumber());
  })

  stackman.callsites(error, { sourcemap: false }, (err, sites) => {
    console.log('=== sourcemap: false ===');
    console.log('Does site[0] have sourcemaps? ' + ('sourcemap' in sites[0]));
    console.log('What line is site[0]? ' + wrapCallSite(sites[0]).getLineNumber());
  })
}

Output, which is now correct:

$ node index
=== sourcemap: false ===
Does site[0] have sourcemaps? false
What line is site[0]? 15
=== sourcemap: true ===
Does site[0] have sourcemaps? false
What line is site[0]? 15

The takeaway from this is that you need to call wrapCallSite from 'source-map-support', but you need to make sure that it's the same module as used from babel-register, otherwise you will have duplicate modules that are configured differently.

I'll try transpiling the above with babel and see if it parses correctly. I'll follow up shortly.

[edongashi]

Having set "sourceMaps": "inline" in babelrc, and having called babel index.js -o test.js, it generated a file with the inline source map in the last line as following:

//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3V....

Calling with sourcemap: true gives the correct output.

$ node test
=== sourcemap: false ===
Does site[0] have sourcemaps? false
What line is site[0]? 17
=== sourcemap: true ===
Does site[0] have sourcemaps? true
What line is site[0]? 15

So yeah, the problem is the memory mapping.

[watson]

I see, thanks a lot for helping me debug this.

This module doesn't parse the err.stack string, but instead hooks into the V8 stack trace API where it can get access to richer information. So even when babel-register makes use of the source-map-support module, it unfortunately doesn't benefit us in this situation.

Instead this modules finds the sourceMappingURL comment by reading the transpiled file from disk and seeks to the end of the file where it looks for the comment. This obviously only work for pre-transpiled files.

I currently don't have a good way of supporting this unfortunately. Suggestions would be highly appreciated 😃