VM: Add source mapping support

[GabrielRatener]

• Version: v6.3.1
• Platform: Darwin Kernel Version 14.5.0
• Subsystem: vm

Currently the VM module supports an options object, such that you can run

const vm = require('vm');

vm.runInNewContext(code, context, options);

The options object currently supports the filename, lineOffset, and columnOffset properties which can all be used to provide better error messages. But wouldn't it be best to let the use provide a function that could map an error location in running code to a location in a source file? It seems lineOffset, and columnOffset are very limited in what they can do relative a mapping function.

Suppose options could have a property resolveLocation, such that options.resolveLocation was a function that took an object {row, column} as a parameter, and returned a {row, column, filename} object representing the location in the original source. This would make filename, lineOffset, and columnOffset all obsolete.

Such a feature would make transpiled code running in a VM context far easier to debug.

Any thoughts?

[bnoordhuis]

See #6471 for discussion about source map support. To summarize, to get decent performance it would need native support from V8.

(If you just want to rewrite exceptions that bubble up from the vm context, you can already do that, of course; that doesn't require core support.)

I'll close the issue. If you want to continue the conversation, please chime in on the other issue.

[GabrielRatener]

@bnoordhuis #6471 is a general discussion on source map support. What I am proposing is a specific feature for the VM module that consists of a single function, and without source mapping URLs like in browsers.

Users of the API I proposed could implement their function using source maps, or anything else they wanted. It is far more flexible than what is being proposed in #6471.

To summarize, to get decent performance it would need native support from V8.

OK, but I don't see performance being a real issue, as we only need to transform the stack trace when it is being displayed and the program is probably going to terminate anyways, right?

(If you just want to rewrite exceptions that bubble up from the vm context, you can already do that, of course; that doesn't require core support.)

Unless there is a trick that I am unaware of, tracking all stack traces that have a VM component is practically impossible. You can wrap the vm.runInNewContext call in a try/catch, then rewrite the caught errors. But some errors may occur later when a function from the context is called from outside.

[bnoordhuis]

You can wrap the vm.runInNewContext call in a try/catch, then rewrite the caught errors. But some errors may occur later when a function from the context is called from outside.

try/catch is what I mean. For asynchronous errors you can use domains.

Much as I hate domains, this is a use case it's pretty good for.

[addaleax]

Also, just an idea, but you could try using V8’s stack trace API to make your own stack traces. Since every VM context has its own Error object, that might just be a tool to do exactly what you want.