• Version all:
• Platform all:
• Subsystem: coverage,testing:

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

• Accurate stack-traces and test coverage tracking, regardless of whether a module is common-js or ESM.
• A developer writing tooling should not have to know what path a module took through the loader.

Potential Solution

• standardize on a padding size that will be inserted on the first line of a script executed in v8 (e.g., 128 characters); ESM or common-js should pad to this size with a no-op, e.g., throw a bunch of spaces on the end of the header.
• expose this padding size as a global variable so that developers writing tooling can reference this value, rather than hardcoding a value.
• it would also be good to do something similar for shebang handling.

CC: @chrisdickinson, @bmeck, @schuay, @ak239