You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note to maintainers: This is not really actionable at this point and I would have used GitHub Discussions if it is enabled here. Feel free to move to Discussions or close this issue.
Consider this simple transpiled script and source map (generated with rollup)
{"version":3,"file":"main.out.js","sources":["main.js"],"sourcesContent":["export const one = 1\n"],"names":[],"mappings":";;;;AAAY,MAAC,GAAG,GAAG;;;;"}
The export const in main.js is not included in the source map. Given only the V8 coverage data, the source map and the file contents, there is no way to distinguish if such ranges are syntactic constructs that are not executable (e.g. export const here) or executable code that is not included in the generated file (e.g. treeshaken functions). As far as I can see, this can only be resolved with the AST of the original source, but that does not scale to TypeScript or other compile-to-JS languages.
Simply assuming one or the other is problematic. If we assume unincluded ranges are executable and thus is uncovered code, then the case above would report a non-full coverage when in fact coverage is 100%.
On the other hand, if we assume unincluded ranges are non-executable and treat them as covered code (which is, effectively, the current behavior), then treeshaken functions are treated as covered code when in fact they are uncovered code.
This discussion was converted from issue #149 on June 03, 2021 21:49.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
For background: I have been trying to make a PoC for more robust source map support. I discovered this issue which make me think such a feature is intractable.
Note to maintainers: This is not really actionable at this point and I would have used GitHub Discussions if it is enabled here. Feel free to move to Discussions or close this issue.
Consider this simple transpiled script and source map (generated with rollup)
source-map-visualization
main.js
main.out.js
main.out.js.map
The
export const
inmain.js
is not included in the source map. Given only the V8 coverage data, the source map and the file contents, there is no way to distinguish if such ranges are syntactic constructs that are not executable (e.g.export const
here) or executable code that is not included in the generated file (e.g. treeshaken functions). As far as I can see, this can only be resolved with the AST of the original source, but that does not scale to TypeScript or other compile-to-JS languages.Simply assuming one or the other is problematic. If we assume unincluded ranges are executable and thus is uncovered code, then the case above would report a non-full coverage when in fact coverage is 100%.
On the other hand, if we assume unincluded ranges are non-executable and treat them as covered code (which is, effectively, the current behavior), then treeshaken functions are treated as covered code when in fact they are uncovered code.
Beta Was this translation helpful? Give feedback.
All reactions