Open CWSpear opened 6 years ago
This appears to make it so you can't ignore functions that are exported. Same left/right as above (with and without plugin, respectively):
All other /* istanbul ignore next */
comments are respected except this one (which is the only one that tries to ignore an exported function).
I am seeing this same behavior running tests with Jest (which uses this plugin). As a result, no coverage is reported for an entry point to a library, e.g., something like:
// in index.js
import * as MyLib from './internals';
export { MyLib };
Even if I write a spec for the index file to assert, say, the right stuff is exported for my lib:
// in index.spec.js
import { MyLib } from './index';
describe('the lib', () => {
it('exports the right stuff', () => {
expect(Object.keys(MyLib).length).toBe(1);
});
});
I get no coverage :(
As soon as any other line that "executes code" is included in the module:
// in index.js
import * as MyLib from './internals';
export { MyLib };
const t = true;
then I get 100% coverage... :|
I get the same behaviour with Vue components that export simple objects as well. Such as:
export default {
name: 'WrapLayout',
props: {
orientation: {
type: String,
default: 'horizontal',
},
},
};
I get 0 coverage this way. But when I change it to this:
const WrapLayout = {
name: 'WrapLayout',
props: {
orientation: {
type: String,
default: 'horizontal',
},
},
directives: {
'common-directive': CommonDirective,
},
};
export default WrapLayout;
I get 100% coverage.
Can you try again with the latest jest
/ babel-plugin-istanbul
? The versions of these modules mentioned here use an older version of istanbul with babel 6, the current versions use babel 7, so the situation may have changed.
@coreyfarrell looks like this is still an issue in my case with latest jest (24.1.0) and @babel/preset-env (7.3.4). ive updated my repro repo.
Also an issue for me using Jest and this plugin.
I have absolutely the same issue as @CWSpear created first!
Jest
instrument sources and produce .json reporterbabel-plugin-istanbul
and get second .json
When I merge it with istanbul-merge
I get the issue, see screenshot (Jest on the left side and babel-plugin-istanbul on the right):
My dependencies:
"babel-plugin-istanbul": "^4.1.6",
"jest": "22.4.4",
"babel-core": "6.26.3",
"babel-eslint": "8.2.3",
"babel-jest": "22.4.4",
"babel-loader": "7.1.4",
We do have the same issue. That is very strange. Is there a way to also ignore the import statements in jest?
We do have the same issue. That is very strange. Is there a way to also ignore the import statements in jest?
@link89 What is your dependencies and its versions?
We've used / istanbul ignore file / statements and it works for us. What that does is it deletes the files from the coverage report, and you no longer see them as uncovered. Obviously, if you add any logic in the file except the import/export statements, then you'd need to remove those statements and test the code from there.
I hope it helps.
Reporting from 2022, still having this issue with Jest 27 and babel-plugin-istanbul 6.1.1
I'm using @storybook/test-runner and Next.js Jest tests, and merging the reports with codecov. The problem is that storybook/test-runner (which uses babel-plugin-istanbul) doesn't report imports/exports as statements but jest does. That means a component can have 100% test coverage from storybook/test-runner and 0% coverage from jest, but the merged report will not be 100% because the jest report says the import/export lines are not covered.
I will get like 0/11 Statements covered from Jest and 4/4 statements covered from storybook/test-runner, and merged together I'll get 4/11 statements covered total.
@VickyKoblinski I have the same issue, did you progress on it?
Same problem here. I need to ignore import statement on coverage report from Jest. Have how do this?
Are you guys using babel-plugin-transform-merge-sibling-variables & babel-plugin-transform-modules-commonjs by chance? I found a bug where import sourcemappings are lost. If you can check your sourcemap with https://evanw.github.io/source-map-visualization/ you might be able to confirm this.
I've already located the bug and opened a PR with the fix.
https://github.com/babel/minify/issues/1046 https://github.com/babel/minify/pull/1047
same issue here
FYI, this is an issue in Istanbul itself. I was able to verify this by running NYC directly rather than relying on this plugin. To fix the issue, I had to patch the istanbul-lib-instrument library using patch-package. Note that this patch is specifically for version 4.0.3
, so you may need to adjust it for other versions:
diff --git a/node_modules/istanbul-lib-instrument/dist/visitor.js b/node_modules/istanbul-lib-instrument/dist/visitor.js
index b8c59cd..05749ee 100644
--- a/node_modules/istanbul-lib-instrument/dist/visitor.js
+++ b/node_modules/istanbul-lib-instrument/dist/visitor.js
@@ -497,6 +497,8 @@ const codeVisitor = {
ExportDefaultDeclaration: entries(),
// ignore processing only
ExportNamedDeclaration: entries(),
+ ImportDeclaration: entries(),
+ ImportOrExportDeclaration: entries(),
// ignore processing only
ClassMethod: entries(coverFunction),
ClassDeclaration: entries(parenthesizedExpressionProp('superClass')),
This essentially tells the AST visitor to ignore ImportDeclaration
and ImportOrExportDeclaration
nodes. Not sure why this wasn't in the source initially but it seems to do exactly what we need for our codebase.
@fossage it'd be great to send a PR to that repo
Just realized that my patch above actually breaks coverage in my unit tests with the error:
ERROR: [path to file]:fns is not iterable
.
It works fine in our Cypress tests however and gives us proper coverage counts. I'll continue investigating.
Is it unexpected that this plugin appears to be ignoring
import
andexport
statements (in terms of statement and line counts)?Maybe I have a config issue, but when I just use babel transpilation and the traditional instrumentation (left), it counts the
import
lines, but when I use this plugin (right), it doesn't count them.The
nyc
config in mypackage.json
:My
.babelrc
:My relevant
package.json
scripts
entries:Relevant package versions: