-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: standardize header size prepended before executing scripts in v8 #17256
Comments
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? |
@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 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.) |
I 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
Just double-checking - stack traces should display the correct line/column positions, don't they? cc @hashseed |
@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. |
conversation has moved to #17396 |
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
The text was updated successfully, but these errors were encountered: