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
The bug is related to coverage tool c8 it used to build coverage report for projects that are tested using mock-import.
Loaders
mock-import is a library built on top of loaders, it supports both versions of API. I know that this is experimental technology, anyways I'm using it on my projects, it works amazing and I'm ready for any API changes. By the way second version is better of Loaders API and it is much simpler, BUT would be great if both versions can co-exist without the need of passing NODE_OPTIONS. You don't need to support both versions, but please give ability for userland modules to smooth this differences, and have ability to write polyfil for it.
Why use loaders to mock imports?
Because it feats very well for using mocks in tests in the same way we used mock-require in good old days we had only CommonJS, since we don't have access to cache of EcmaScript Modules. So it's:
✅ ESM friendly;
✅ has ability to by-pass cache using query suffix: ?mock-import-count=x;
✅ changes ImportDeclaration to VariableDeclaration to get mocked code from predefined storage
To get transformations working 🐊Putout code transformer used, it based on Babel.
What is problem with transforming files on-a-fly using Loaders?
The coverage is the problem with mocked files transformed by loading. Since c8 uses NODE_V8_COVERAGE to put coverage on screen.
I have such coverage results that c8 get from coverage directory generated by node: ranges for functionNam=default is different: two positions, three and three. This is conditions, third-one is absent in first report. Why is so?
I would love to! But while I can reproduce the issue, I have not the faintest idea where the problem really is. It seems to be something pretty low level if I read these tickets correctly
Version
v14, v16, v17 latest
Platform
Linux, Darwin
Subsystem
No response
What steps will reproduce the bug?
🐛 What is bug related to?
The bug is related to coverage tool c8 it used to build coverage report for projects that are tested using
mock-import
.Loaders
mock-import
is a library built on top of loaders, it supports both versions ofAPI
. I know that this is experimental technology, anyways I'm using it on my projects, it works amazing and I'm ready for anyAPI
changes. By the way second version is better of Loaders API and it is much simpler, BUT would be great if both versions can co-exist without the need of passingNODE_OPTIONS
. You don't need to support both versions, but please give ability foruserland
modules to smooth this differences, and have ability to write polyfil for it.Why use loaders to
mock imports
?Because it feats very well for using mocks in tests in the same way we used mock-require in good old days we had only
CommonJS
, since we don't have access to cache ofEcmaScript Modules
. So it's:ESM
friendly;?mock-import-count=x
;ImportDeclaration
toVariableDeclaration
to get mocked code from predefined storageTo get transformations working 🐊
Putout
code transformer used, it based on Babel.What is problem with transforming files on-a-fly using
Loaders
?The
coverage
is the problem withmocked files
transformed by loading. Sincec8
usesNODE_V8_COVERAGE
to put coverage on screen.More low level details
You can see here all the story. The thing is for similar code fragments generated different coverage information.
So for code fragment with no transformation:
With mocked first import:
And with mocking second-one
I have such
coverage
results thatc8
get fromcoverage
directory generated bynode
:ranges
forfunctionNam=default
is different:two
positions,three
andthree
. This is conditions, third-one is absent in first report. Why is so?Looks like this is the reason why
c8
shows that lines are not covered. But they are.To reproduce bug clone repository with
What is the bug?
The bug is different coverage information for the same file content.
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior?
Would be great if coverage information was the same for the similar type of content.
What do you see instead?
I see that
coverage
is missing information about code running code parts whenLoaders
are used to transform the source.Additional information
Happy Holidays 🎄! And thank you for the hard work you are doing,
node.js
is the greatest platform 🎉 !The text was updated successfully, but these errors were encountered: