Repository navigation
proposal: standardize header size prepended before executing scripts in v8 #17256
Description
Activity
For shebangs, it has been added to TC39 agenda under "InterpreterDirective" to see if it can be incorporated into the grammars.
Another solution is potentially to just put source maps in all files that are manipulated via source text manipulation by node I think.
Is there a reason it needs to be a number/byte count?
Another solution is potentially to just put source maps in all files that are manipulated via source text manipulation by node I think.
@schuay or @ak239 can better speak to how viable this solution would be -- my main concern would be in whether or not we're running coverage through source-map handling at a point in the stack where it would be easy to take advantage of this information. tldr; I'd love to see v8 test-coverage be a viable solution in Node.js in a reasonable time frame.
Would passing -62 as the column offset to
v8::ScriptOrigin(and thence tov8::ScriptCompiler::CompileUnbound()) work?I remember trying that some years ago and I believe it worked okay except for a bug in the old debugger (which is gone now.)
Reacted by Benjamin E. Coe, Benjamin Gruenbaum and snekI think we should fix this in V8. The problem is that we report source positions without taking wrapper script offsets into account. We should have access to these in
Script::line_offsetandScript::column_offsethere. Opened https://crbug.com/v8/7119.inaccurate stack traces
Just double-checking - stack traces should display the correct line/column positions, don't they?
cc @hashseed
Reacted by Benjamin Gruenbaum and Benjamin E. Coe@bnoordhuis thanks for helping point us in the right direction, we have some work in progress now that applies column/line offset to the coverage positions.
Off the top of your head, should these values being set appropriately when a script is currently executed in v8? I was reading this comment and didn't quite follow the current state of affairs.
Problem
I've been working with folks on the v8 team to try to move towards using v8's built in coverage as a viable way to collect coverage for Node.js scripts outside of the browser.
When a common-js module is executed in v8, the script is wrapped in a closure which introduces 62 additional bytes to the first line of the application. When an ES module is executed I believe it introduces a different byte count (there's actually no wrapper?).
It's difficult for tooling that instruments JavaScript source to predict what header might have been inserted on a source file before it was executed in v8; This leads to inaccurate stack traces and coverage reports.
Goals
Potential Solution
CC: @chrisdickinson, @bmeck, @schuay, @ak239