Took me a while to figure out what was actually going on but I've discovered an issue whereby a locally scoped variable which has the same name as the enclosing parent function results in coverage not being generated for that function.

Expected Behavior

Coverage report generated for all files under test.

Observed Behavior

Not all files are reported

Bonus Points! Code (or Repository) that Reproduces Issue

Here is a contrived example and project.

module.exports = function sum (...args) {

    let sum = args.reduce((acc, value) => {
        acc += value;
        return acc;
    }, 0);

    return sum;
};

https://github.com/indieisaconcept/istanbul-issue-example

Forensic Information

Operating System: : OSX 10.12.3
Environment Information: indieisaconcept/a793194bd7a31ea1905a0b92c43c10f3

Below is a screenshot showing a difference between lcov reports from istanbul and nyc. I am trying to migrate from istanbul but in order to safely do so I would preferably like to see same coverage numbers.
My request is about ability to reproduce istanbul behavior in nyc.

Note, I am not the only one suffering from this issue as proven by this problem reported to Codecov https://github.com/codecov/support/issues/391

Many thanks for the great tool which is nyc!

This function starts to return false after instrumentation:

function test () {
  var foo = class {};
  var bar = class baz {};
  var qux = class { static name() {} };
  return foo.name === "foo" &&
         bar.name === "baz" &&
         typeof qux.name === "function";
}

This is the test for variables (class) in the node-compat-table for function names. See source.

The instrumentation yields:

  var foo = (++cov_2mofekog2n.s[0], class {});
  var bar = (++cov_2mofekog2n.s[1], class baz {});
  var qux = (++cov_2mofekog2n.s[2], class {
    static name() {
      ++cov_2mofekog2n.f[1];
    }
  });

Do the class expressions need to be instrumented? For comparison, with var foo = function() {}; the output is:

  var foo = function () {
    ++cov_2mofekog2n.f[1];
  };

See also https://github.com/novemberborn/function-name-support which contains a regression test for istanbul-lib-instruments behavior.

We are also having a similar issue as #70 when using istanbul for code coverage in our Angular2 application that uses the standard @input decorator.

import { Component, Input } from '@angular/core';
import { PluginOptions } from '../../../plugin-contracts';
import { Template } from '../../../plugin-contracts';
 
@Component({
    selector: 'angular-component',
    templateUrl: './angular-component.component.html',
    styleUrls: ['./angular-component.component.scss'],
})
export class AngularComponent {
    /* istanbul ignore next */
    @Input()
    pluginOptions: PluginOptions;
 
    /* istanbul ignore next */
    @Input()
    template: Template;
}

Here is the typedef for the @input decorator:

/**
 * Type of the Input metadata.
 *
 * @stable
 */
export interface Input {
    /**
     * Name used when instantiating a component in the template.
     */
    bindingPropertyName?: string;
}

The code coverage shows up as missing branches in the @input decorator which is just an interface. Is it because it is an optional property? There is no way to directly cover this.

Any ideas?

Version 10.3.2 of nyc just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As nyc is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

For some reasons, we sometimes declare variables in Switch Case clauses by the const keyword. To bring that to work, we have to add curly braces around the "case body" like in the 'bar' case below:

switch (foo) {
    case 'bar': {
        const foo2 = foo * 2;

        return foo2;
    }
    case 'baz':
        return foo + 1;
    default:
        return foo;
}

Now, if I create unit tests for all those three cases, the HTML report says that the statements in 'baz' and default was not covered.

I am using the recent release of nyc, npm v2.14.20 and node v4.4.0 (using nvm) on Ubuntu 16.04.

I would be glad to read if it's intended to support this syntactic feature or not.

I think the coverage rate here is right, but it seems the red color is wrong.

Way to reproduce:

git clone [email protected]:Stupidism/react-starter-kit.git -b feat/test-coverage
cd react-starter-kit
yarn install 
yarn run coverage 

I think we need to add hook to vm.runInContext in a similar way that we hook vm.runInThisContext. Maybe for vm.runInNewContext as well.
Because some projects need to use vm.runInContext to create a testing context for code that is supposed to run in that context.

Move to a real domain name. (Please don't post domain suggestions)

I'm trying to make my own istanbul coverage reporter, but I can't find any kind of documentation that explains how I'd make my own and actually have nyc recognize it as a valid reporter.

I've looked through the source code, and I can see that if I manually add my own code to node_modules/nyc/node_modules/istanbul-reports/lib/myCustomReporter/index.js that I can then use it in
nyc --reporter=myCustomReporter mocha

Is there some documentation you could point me to in order to help me out with this?

Thanks for any help you can give me here.

Hello all,

Thanks for great work, and sorry if this is not the right forum to ask this question.

As you can see from the image above, the constructor params are considered branch and are not covered, the rest of the class is 100% expect the constructor.

Can you tell me why it is counting the constructor as branches, and how can I fix it, please?

"istanbul-lib-hook" is depended of "append-transform": "^0.4.3"

moved from istanbuljs/nyc#598 (comment)

Please use the template provided below, when reporting bugs:

Expected Behavior

Packages should be 100% with cobertura report if test files is under one folder
The right cobertura xml file should be as below (generated by istanbul directly):

Observed Behavior

Packages is N/A with cobertura report if test files is under one folder

Bonus Points! Code (or Repository) that Reproduces Issue

Forensic Information

Operating System: OS X Sierra 10.12.5
Environment Information: node 6.10.3, npm 3.10.10

Yeah, I opened this at archived repo istanbuljs/test-exclude#28. Sorry for the mess.

Description:

This case is from istanbuljs/nyc#554. Reopened here as suggested by @bcoe. Anything mentioned there applies. All files listings and version info located at Gist. More specifics follows:

Problem:

Directory junctions on windows systems do not excluded from paths correctly.

Case:

First, a structure example. Here, dir is simple directory, while junc is junction to dir (made with mklink /j junc dir)

`-- expr
  +-- dir
  | `-- foo.js
  +-- junc >> dir
  +-- main.js
  `-- package.json

main.js is simple test:

const assert = require('assert')

const exclude = require('test-exclude')

const junctionOnly = exclude({
  exclude: ['dir/']
})

assert.strictEqual(false, junctionOnly.shouldInstrument('dir/foo.js')) // GOOD
assert.strictEqual(true, junctionOnly.shouldInstrument('junc/foo.js')) // GOOD

const plainDirOnly = exclude({
  exclude: ['foo/']
})

assert.strictEqual(true, plainDirOnly.shouldInstrument('dir/foo.js')) // GOOD
assert.strictEqual(false, plainDirOnly.shouldInstrument('junc/foo.js')) // BAD

You can see that assert fails at excluding junctioned path.

First of all thank you for maintaining this great library and for all the work 👏 Hope this is a good place to ask this question.

Basically, I am trying to generate report from window.__coverage__ object, with partial success. It seams that easiest way to to this would be using nyc, which as I see only supports creating report from existing .nyc_output folder.

Is there a straightforward way to get to .nyc_output folder from __coverage__ object? If not, what would be the right direction to go?

Thanks for reading ✌️

Version 10.3.0 of nyc just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As nyc is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Could I convince to reopen this issue on the istanbuljs monorepo?

Done.

istanbuljs-archived-repos/istanbul-lib-source-maps#9

I installed istanbul 0.4.5 but upon running I get an error with the html reporter

Error: ENOENT: no such file or directory, scandir '../node_modules/nyc/node_modules/istanbul-reports/lib/html/assets'
at Object.fs.readdirSync (fs.js:871:18)

checking my node_modules directory , effectively te assets directory is NOT installed ..

I originally reported this over at gotwarlost/istanbul#810, but it looks like that repo is no longer maintained?

I'm getting "Branch Not Covered" warnings for code, seemingly starting from any logical operator (see this screenshot) and run to the end of the file. Removing the logical operator fixes the erroneous error, but it crops up again at the next logical operator. This only seems to happen for "branch not covered" warnings, "statement not covered" errors appear to be correct, even if in the middle of a "branch not covered" warning.

I'm using Istanbul version 1.0.0-alpha.2, and Jasmine version 2.6.0, with Babel to transpile from es6. I've set up my babel config and it seems to be working (jasmine tests run fine), and Istanbul is giving me code coverage metrics that seem right.

Here's a case: https://gist.github.com/isaacs/0d013bb96063f379242fba37f45ece63

Should be 100% test coverage. Using nyc 10.2.0 it was. But in nyc 11, it no longer is.

I have an idea about how I'd like to do this, and basically just need to take the time to implement.

I'd like to generate a CHANGELOG for each project in /packages, as versions are released.

I've created a tracking issue here: conventional-changelog/standard-version#156

(see istanbuljs/nyc#569 for original report, re-filed here at @bcoe's request)

Expected Behavior

Adding an negated exclude pattern would cause nyc to run against files that match the negated exclude pattern. I.e.:

$ nyc -x "foo/**" -x "!foo/bar.js"
# all of ./foo/ is ignored, except for ./foo/bar.js

Observed Behavior

Using the example above, nyc ignores all of ./foo/, including (incorrectly) ./foo/bar.js. In addition, including any negation pattern in your exclude list appears to remove the default **/node_modules/** exclusion patterns.

Forensic Information

Operating System: macOS 10.12.4
Environment Information: https://gist.github.com/davewasmer/9d98fb190a0080329923b8c1a2e9c303

I believe I tracked it down to this block in test-exclude, where it seems like you are trying to find negation patterns that would end up negating the default node_modules exclusion pattern:

// I rearranged this block to make it easier to demonstrate, but it's functionally equivalent ...
var negationAllowed = !!micromatch('./node_modules/foo.js', pattern, {nonegate: false}).length;
var negationIgnored = !!micromatch('./node_modules/foo.js', pattern, {nonegate: true}).length;
var negated = negationAllowed !== negationIgnored;

If we run this with !**/node_modules/** as our pattern, we can see:

var negationAllowed = !!micromatch('./node_modules/foo.js', '!**/node_modules/**', {nonegate: false}).length; // false
var negationIgnored = !!micromatch('./node_modules/foo.js', '!**/node_modules/**', {nonegate: true}).length; // true
var negated = negationAllowed !== negationIgnored; // true

I think the intention here was to pick up on any negated pattern applying to node_modules - if ignoring negations caused a match against node_modules/foo.js, then the pattern must be trying to negate node_modules.

However, a negated pattern will match anything that doesn't match the pattern. So this ends up working the other way around when checking any arbitrary negated pattern:

var negationAllowed = !!micromatch('./node_modules/foo.js', '!whatever', {nonegate: false}).length; // true <- this is the problem, the random negated pattern matches here
var negationIgnored = !!micromatch('./node_modules/foo.js', '!whatever', {nonegate: true}).length; // false
var negated = negationAllowed !== negationIgnored; // true

The end result here is that any negated pattern in the exclude option results in:

• That negated pattern being removed from the exclude option
• The default node_modules exclude pattern being removed

In the text reporter, if all lines are covered, print the lines that have uncovered branches.

This is really frustrating, because I get 100% on all 4 columns 100% of the time locally, but I get this weird result sometimes on Travis, and I have no idea what branch is going uncovered:

  pack.js          |      100 |    98.98 |      100 |      100 |                |

https://travis-ci.org/npm/node-tar/jobs/225815062

Is it possible to use Istanbul to track the flow of an application at runtime (not for test) ?
The idea is instrumenting the code to trace the functions used during execution.
Thx

lerna ERR! execute Error: spawn yarn ENOENT
lerna ERR! execute at notFoundError (C:\Users\rpang27\Desktop\GitHub\istanbuljs\node_modules\cross-spa
wn\lib\enoent.js:11:11)
lerna ERR! execute at verifyENOENT (C:\Users\rpang27\Desktop\GitHub\istanbuljs\node_modules\cross-spaw
n\lib\enoent.js:46:16)
lerna ERR! execute at ChildProcess.cp.emit (C:\Users\rpang27\Desktop\GitHub\istanbuljs\node_modules\cr
oss-spawn\lib\enoent.js:33:19)
lerna ERR! execute at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
lerna ERR! execute callback with error
lerna ERR! execute { Error: spawn yarn ENOENT
lerna ERR! execute at notFoundError (C:\Users\rpang27\Desktop\GitHub\istanbuljs\node_modules\cross-spa
wn\lib\enoent.js:11:11)
lerna ERR! execute at verifyENOENT (C:\Users\rpang27\Desktop\GitHub\istanbuljs\node_modules\cross-spaw
n\lib\enoent.js:46:16)
lerna ERR! execute at ChildProcess.cp.emit (C:\Users\rpang27\Desktop\GitHub\istanbuljs\node_modules\cr
oss-spawn\lib\enoent.js:33:19)
lerna ERR! execute at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)
lerna ERR! execute stack: 'Error: spawn yarn ENOENT\n at notFoundError (C:\Users\rpang27\Desktop\
GitHub\istanbuljs\node_modules\cross-spawn\lib\enoent.js:11:11)\n at verifyENOENT (C:\Users\rpan
g27\Desktop\GitHub\istanbuljs\node_modules\cross-spawn\lib\enoent.js:46:16)\n at ChildProcess.cp
.emit (C:\Users\rpang27\Desktop\GitHub\istanbuljs\node_modules\cross-spawn\lib\enoent.js:33:19)\n
at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)',
lerna ERR! execute errno: 'ENOENT',
lerna ERR! execute code: 'ENOENT',
lerna ERR! execute syscall: 'spawn yarn',
lerna ERR! execute killed: false,
lerna ERR! execute stdout: '',
lerna ERR! execute stderr: ''yarn' is not recognized as an internal or external command,\r\noperable p
rogram or batch file.\r\n',
lerna ERR! execute failed: true,
lerna ERR! execute signal: null,
lerna ERR! execute cmd: 'yarn install --mutex network:42424 --non-interactive',
lerna ERR! execute timedOut: false }

can't seem to find exactly what package this is caused from, but here's the output:

Start time: (2017-09-09 16:48:46 UTC) [treshold=1%]  <===== TYPO HERE
#  module  time  %
Total require(): 788
Total time: 43.6s

jestjs/jest#3158

paste:

--coverage opt broke my tests, why?

I have two scripts at my repo's package. https://github.com/k1r0s/kaop

    "test": "jest",
    "coverage": "jest --coverage",

´coverage´ fails but ´test´ runs as spected. Why?

Important note: My tests modify some of my source files to test hot reloading, and I think the file changes are confusing the lcov reporter. Not sure if you have any intention to support files changing in the middle of tests.

Expected Behavior

I'm able to create an lcov report with nyc

Observed Behavior

nyc crashes with the following output. I've only seen this happen with the lcov reporter; the json and text reporters succeed.

/Users/andy/crater/node_modules/nyc/node_modules/istanbul-reports/lib/lcovonly/index.js:32
        writer.println('FN:' + [meta.decl.start.line, meta.name].join(','));
                                    ^

TypeError: Cannot read property 'decl' of undefined
    at /Users/andy/crater/node_modules/nyc/node_modules/istanbul-reports/lib/lcovonly/index.js:32:37
    at Array.forEach (native)
    at LcovOnlyReport.onDetail (/Users/andy/crater/node_modules/nyc/node_modules/istanbul-reports/lib/lcovonly/index.js:30:28)
    at LcovReport.(anonymous function) [as onDetail] (/Users/andy/crater/node_modules/nyc/node_modules/istanbul-reports/lib/lcov/index.js:21:24)
    at Visitor.(anonymous function) [as onDetail] (/Users/andy/crater/node_modules/nyc/node_modules/istanbul-lib-report/lib/tree.js:34:30)
...

I ran it in the debugger and discovered that the node has an extraneous NaN element in node.getFileCoverage().f, making it 1 element longer than the other corresponding arrays:

Bonus Points! Code (or Repository) that Reproduces Issue

Not the minimum repo by any means, but you should be able to reproduce it with:

git clone [email protected]:jcoreio/crater
cd crater
git checkout coverage
npm install
npm run coverage

It's happening on this file:

crater/src/server/index.js:

/* @flow */

import express from 'express'
import path from 'path'
import createSSR from './createSSR'
import { WebApp } from 'meteor/webapp'

import '../universal/collections/Counts'

const app = express()
app.get("/test", (req, res) => res.send("hello world"))
app.get("/test", (req, res) => res.send("hello world"))

app.use((req: Object, res: Object, next: Function) => {
  if (/\/favicon\.?(jpe?g|png|ico|gif)?$/i.test(req.url)) {
    res.status(404).end()
  } else {
    next()
  }
})

if (process.env.NODE_ENV === 'production') {
  app.use('/static', express.static(path.resolve(__dirname, 'static')))
}

// server-side rendering
app.get('*', (req: Object, res: Object, next: Function) => {
  // let Meteor handle sockjs requests so that DDP works
  if (/^\/sockjs/.test(req.path)) {
    next()
    return
  }
  createSSR(req, res)
})

WebApp.rawConnectHandlers.use(app)

console.log(`App is listening on http://0.0.0.0:${process.env.PORT || '80'}`) // eslint-disable-line no-console

Forensic Information

Operating System: OS X 10.11.6
Environment Information: https://gist.github.com/jedwards1211/7fbeef7cf1294df370e41227df41e94a

Related to #14.

Cobertura condition-coverage for branches is not recorded correctly. There is an issue (istanbuljs/nyc#530) with detailed information on observed/expected behavior as well as the quick fix I am currently using at work.

The fix is easy enough to do, but it breaks the "base coverage returns branch coverage by line" test for the istanbul-lib-coverage package. My initial solution:

var line = branchMap[k].line || branchMap[k].loc.start.line

Other packages in this repo prefer the "fixed" shape, so it seems that this fix should be safe to do without breaking anything else.

originally reported in jestjs/jest#3491

i was able to reproduce locally.
after i downgraded istanbul-api by doing yarn add [email protected] the problem seemed to go away.
i wasn't able to reproduce it on other projects, just the one in the issue.
any ideas what could have caused it?

The code doesn't honor sourceRoot property at all, which Chrome correctly treats it by concatenating sourceRoot with sources. Such maps are mainly generated by gulp-sourcemaps.

The test should be altered to have a version with sourceRoot.

On some of my files the html reporting is failing. Instead of rendering the source code annotated with coverage it is rendering the following stack trace:

Cannot read property 'start' of undefined
TypeError: Cannot read property 'start' of undefined
    at /Users/snels/projects/halo-api/node_modules/nyc/node_modules/istanbul-reports/lib/html/annotator.js:50:28
    at Array.forEach (native)
    at annotateStatements (/Users/snels/projects/halo-api/node_modules/nyc/node_modules/istanbul-reports/lib/html/annotator.js:46:33)
    at Object.annotateSourceCode (/Users/snels/projects/halo-api/node_modules/nyc/node_modules/istanbul-reports/lib/html/annotator.js:193:9)
    at HtmlReport.onDetail (/Users/snels/projects/halo-api/node_modules/nyc/node_modules/istanbul-reports/lib/html/index.js:217:39)
    at LcovReport.(anonymous function) [as onDetail] (/Users/snels/projects/halo-api/node_modules/nyc/node_modules/istanbul-reports/lib/lcov/index.js:24:24)
    at Visitor.(anonymous function) [as onDetail] (/Users/snels/projects/halo-api/node_modules/nyc/node_modules/istanbul-lib-report/lib/tree.js:34:30)
    at ReportNode.Node.visit (/Users/snels/projects/halo-api/node_modules/nyc/node_modules/istanbul-lib-report/lib/tree.js:123:17)
    at /Users/snels/projects/halo-api/node_modules/nyc/node_modules/istanbul-lib-report/lib/tree.js:116:23
    at Array.forEach (native)

Digging into the that stack trace it looks like html/annotator.js assumes that fileCoverage.s and fileCoverage.statementMap are always the same length.

var statementStats = fileCoverage.s,
        statementMeta = fileCoverage.statementMap;
    Object.keys(statementStats).forEach(function (stName) {
        var count = statementStats[stName],
            meta = statementMeta[stName],
            type = count > 0 ? 'yes' : 'no',
            startCol = meta.start.column,
            endCol = meta.end.column + 1,
            startLine = meta.start.line,
            endLine = meta.end.line,
            openSpan = lt + 'span class="' + (meta.skip ? 'cstat-skip' : 'cstat-no') + '"' + title('statement not covered') + gt,
            closeSpan = lt + '/span' + gt,
            text;

However in the case where it fails this is not the case. In my case, the lcov.info file s contains extra entries ('statementMap' only has entries up to "16"):

"s": {
      "0": 2,
      "1": 4,
      "2": 5,
      "3": 4,
      "4": 2,
      "5": 1,
      "6": 4,
      "7": 4,
      "8": 3,
      "9": 3,
      "10": 4,
      "11": 6,
      "12": 4,
      "13": 4,
      "14": 6,
      "15": 4,
      "16": 4,
      "17": null,
      "18": null,
      "19": null
    },

This could easily be fixed by filtering the keys or adding a guard clause inside the forEach handling function.

I am trying to use nyc on my ES2015 code, having followed the guide. However, when the coverage report is generated, all instance methods of a class are reported as named "anonymous_x". I'm getting a similar result on methods defined on a prototype, but I'll omit that issue for now.

When running:

cross-env NODE_ENV=test nyc mocha "js/**/*.spec.js"

against:

.babelrc

{
    "presets": ["es2015"],
    "plugins": ["istanbul"]
}

Demo.js

export class Demo {
    constructor() {
        this.value = 1;
    }

    getValue() {
        return this.value;
    }

    print() {
        console.log(this.toString());
    }

    toString() {
        return this.value.toString();
    }
}

Demo.spec.js

import {Demo} from "./demo";

describe("demo", function() {
    it("Gets values", function() {
        let demo = new Demo();
        expect(demo.getValue()).to.eql(1);
    });
});

package.json

{
...
  "scripts": {
    "coverage": "cross-env NODE_ENV=test nyc mocha \"js/**/*.spec.js\""
  },
  "nyc": {
    "reportDir": "coverage",
    "require": [
      "babel-register"
    ],
    "include": [
      "js/**/*.js"
    ],
    "exclude": [
      "js/**/*.spec.js"
    ],
    "sourceMap": false,
    "instrument": false,
    "reporter": ["lcov"],
    "cache": true
  },
  "devDependencies": {
    "babel-cli": "^6.24.1",
    "babel-core": "^6.24.1",
    "babel-plugin-istanbul": "^4.1.4",
    "babel-preset-es2015": "^6.24.1",
    "babel-register": "^6.24.1",
    "chai": "^3.5.0",
    "cross-env": "^5.0.0",
    "mocha": "^3.4.2",
    "nyc": "^11.0.2-candidate.0",
    "sinon": "^2.0.0",
    "sinon-chai": "^2.10.0"
  }
...
}

the output is:

TN:
SF:/my/path/to/nyctest/js/demo.js
FN:2,(anonymous_0)
FN:6,(anonymous_1)
FN:10,(anonymous_2)
FN:14,(anonymous_3)
FNF:4
FNH:2
FNDA:1,(anonymous_0)
FNDA:1,(anonymous_1)
FNDA:0,(anonymous_2)
FNDA:0,(anonymous_3)
DA:3,1
DA:7,1
DA:11,0
DA:15,0
LF:4
LH:2
BRF:0
BRH:0
end_of_record

When running:

istanbul cover _mocha -- --bail --require babel-polyfill --compilers js:babel-register

Using babel preset latest and plugin istanbul, I get the following errors (just messages, no stack traces), and they are swallowed somewhere, resulting in the tests subsequently running but no coverage report being generated.

Transformation error for /home/mark/ef/oc/qb/marshall/src/main.js ; return original code
Cannot read property 'fileCoverage' of undefined
Transformation error for /home/mark/ef/oc/qb/marshall/src/endpoint/db.js ; return original code
Cannot read property 'fileCoverage' of undefined
Transformation error for /home/mark/ef/oc/qb/marshall/src/config/index.js ; return original code
Cannot read property 'fileCoverage' of undefined
Transformation error for /home/mark/ef/oc/qb/marshall/src/config/db.js ; return original code
Cannot read property 'fileCoverage' of undefined
... et cetera ...

I've narrowed it down to istanbul-lib-instrument/dist/instrumenter.js, function instrumentSync, line 147 (dist), line 100 (source):

this.fileCoverage = output.fileCoverage;

I'm using babel-plugin-istanbul version:

      "version": "4.1.4",
      "integrity": "sha1-GN3oS/POMp/d8/QQP66SFFbY5Yc=",

And istanbul-lib-instrument version:

      "version": "1.7.3",
      "integrity": "sha1-klsjkWPqvdaMxASPUsL6T4mez6c=",

I see that output is initialised to {}, then reassigned in the AST visitor exit callback output = ee.exit(path). So ee.exit is returning undefined at some point,

@jamestalmage could you give me npm publish permissions for append-transform?

I've been consolidating the Istanbul utility libraries into a monorepo; I feel it makes the org a little easier to dive into.

Some time ago I created "hacky" way of getting some UX improvements to HTML Istanbul report. I would love to make these improvements available to all developers, so I plan to port them (or just a part we agree on) to Istanbul source.

Would be great if you could let me know if you like this idea or not, so I can proceed with preparing clean implementation. :)

Please check live demo I managed to generate for Istanbul sources.

Problems with current design:

• hard to read, flat list, noisy design
• navigation between static pages, loosing context

New design:

• tree structure
• opening file coverage in modal dialog
• summary chart with meaningful info/warning

Known issues/limitations of current implementation:

• iziModal behavior when displaying report in iframe
• missing routing (cannot share link to an open modal)
• report should rather be served on the server in order to fetch all pages

The cobertura xml report (generated via nyc report --reporter=cobertura) appears to be invalid.
Please consider cobertura-coverage.zip.

The following snippet illustrates the problems:

<?xml version="1.0" ?>
<!DOCTYPE coverage SYSTEM "http://cobertura.sourceforge.net/xml/coverage-04.dtd">
<coverage lines-valid="446" lines-covered="442" line-rate="0.991" branches-valid="278" branches-covered="264" branch-rate="0.9495999999999999" timestamp="1489774044213" complexity="0" version="0.1">
  <sources>
    <source>/home/travis/build/testspace-open/dockerfilelint</source>
  </sources>
  <packages>
    <class name="apk.js" filename="lib/apk.js" line-rate="1" branch-rate="1">
...
    </class>
  </packages>
</coverage>

• there is a missing package tag that is supposed to be a child of the packages tag
• there is a missing classes tag that is supposed to wrap all the class tags

Expected output:

<?xml version="1.0" ?>
<!DOCTYPE coverage SYSTEM "http://cobertura.sourceforge.net/xml/coverage-04.dtd">
<coverage lines-valid="446" lines-covered="442" line-rate="0.991" branches-valid="278" branches-covered="264" branch-rate="0.9495999999999999" timestamp="1489774044213" complexity="0" version="0.1">
  <sources>
    <source>/home/travis/build/testspace-open/dockerfilelint</source>
  </sources>
  <packages>
    <package name="lib" line-rate="1" branch-rate="1">
      <classes>
        <class name="apk.js" filename="lib/apk.js" line-rate="1" branch-rate="1">
...
        </class>
      </classes>
    </package>
  </packages>
</coverage>

Hi,

I've got a fun little setup.

I'm running mocha instrumented with nyc, like nyc -n src -i babel-core/register mocha. In itself, this part works.
Most of the tests are unit-tests running directly in the nodejs instance. Other tests are end-to-end tests which start a webdriver-controlled browser, bundle sourcefiles with webpack using babel and istanbul-instrumenter-loader, then do some browser tests and send window.__coverage__ back to the test-runner via the webdriver connection. The test runner then writes out the source-mapped coverage data to .nyc_output (with a little help from istanbul-api) where it gets picked up by nyc and reported. This works too.

However, if I run both the normal testsuite and the end-to-end tests in the same mocha run, the manually written coverage overrides coverage data from nyc. That is, if I have 100% coverage on src/thing.js in the regular tests, but only 70% in the end-to-end tests, nyc reports only 70%.

Is there something I can do to somehow funnel the browser's coverage data into the running nyc instance?

I would like to be able to check coverage on one file, or a short list of files.

There are a few ways this could be done. It seems that the least invasive method would be to add something to the config. These options would only be present for check coverage, as I think the use case of checking the coverage of a single file is more likely than only generating coverage for a single file.

The options are:

• add an "includes" entry that is mutually exclusive from the "excludes" entry (ie, only one can be present or an error is thrown)
• modify excludes so that you can add a NOT modifer. Such as:

  excludes:
    - NOT src/myfiles.js

While it is a less pretty change it does have the benefit of isolating the work to the removeFiles function (https://github.com/istanbuljs/istanbuljs/blob/master/packages/istanbul-api/lib/run-check-coverage.js#L14)

I'd like to implement this as it will help us with some workflows we are trying to implement. Any advice on the best route forward?

jestjs/jest#3158

paste:

--coverage opt broke my tests, why?

I have two scripts at my repo's package. https://github.com/k1r0s/kaop

    "test": "jest",
    "coverage": "jest --coverage",

´coverage´ fails but ´test´ runs as spected. Why?

This was originally an issue posted on this project: istanbuljs/nyc#625, and generated interest. They felt this project was more appropriate for the question/issue and requested I repost here.

Expected Behavior

Report branch coverage for .then() Bluebird statements with function short-hand. This example queries a database and then collects a result:

query.execAsync()
    .then(result => result.Items)
    .map(item => item.toJSON())
    // TODO - nyc coverage reports missing branch here incorrectly.
    .then((exportFormats = []) => ({exportFormats}));

Observed Behavior

Coverage is not reported for the above noted line, even though console logs inserted confirm code execution. Branch coverage will also miss this newly installed code:

query.execAsync()
    .then(result => result.Items)
    .map(item => item.toJSON())
    // TODO - nyc coverage reports missing branch here incorrectly.
    .then((exportFormats = []) => {
        console.log('RUNNING');
        return {exportFormats};
    });

Bonus Points! Code (or Repository) that Reproduces Issue

Private code, but will create a public version if needed.

Forensic Information

Operating System: OSX 10.12.5
Environment Information: information about your project's environment, see instructions below:

1. run the following script:

sh -c 'node --version; npm --version; npm ls' > output.txt

2. share a gist with the contents of output.txt.
   https://gist.github.com/cblair/80a87a3de827e9fd10936357efca0aa1

I'm getting an error trying to install [email protected] with the error:

npm ERR! notarget No compatible version found: append-transform@^0.4.3
npm ERR! notarget Valid install targets:
npm ERR! notarget 0.4.0, 0.3.0, 0.2.2, 0.2.1, 0.2.0
npm ERR! notarget
npm ERR! notarget This is most likely not a problem with npm itself.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.
npm ERR! notarget
npm ERR! notarget It was specified as a dependency of 'istanbul-lib-hook'

This was originally due to my dependency on jest-cli. I see that the [email protected] was tagged, but is not showing up in my npm info append-transform output.

Version 2.1.0 of lerna just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As lerna is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Hello @bcoe,

We got this error today. I opened the issue here, because I didn't find the repository of istanbul-lib-instrument.

error	17-Jul-2017 09:34:02	npm ERR! notarget No compatible version found: istanbul-lib-instrument@^1.7.4
error	17-Jul-2017 09:34:02	npm ERR! notarget Valid install targets:
error	17-Jul-2017 09:34:02	npm ERR! notarget 1.7.3, 1.7.2, 1.7.1, 1.7.0, 1.6.2, 1.6.1, 1.6.0, 1.5.0, 1.4.2, 1.4.1, 1.4.0, 1.4.0-candidate.0, 1.3.1, 1.3.0, 1.2.0, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.1.0-alpha.4, 1.1.0-alpha.3, 1.1.0-alpha.2, 1.1.0-alpha.1, 1.1.0-alpha.0, 1.0.0-alpha.6, 1.0.0-alpha.5, 1.0.0-alpha.4, 1.0.0-alpha.3, 1.0.0-alpha.2, 1.0.0-alpha.1, 1.0.0-alpha.0

Thanks

As mentioned in this comment, Istanbul's function munging can interfere with cases where a program is relying on function.toString(). It seems possible (in theory at least) to preserve this by capturing the toString() result of the original function.

Example:

// t.js
const f = () => x = 100
console.log(f.toString())

$ node t.js
() => x = 100

$ nyc node t.js
()=>{cov_2bdy3zmxoh.f[0]++;cov_2bdy3zmxoh.s[1]++;return x=100;}

// s.js
const f = () => x = 100
f.toString = () => '() => x = 100'
console.log(f.toString())

$ node s.js
() => x = 100

$ nyc node s.js
() => x = 100

I'm not interested in debating whether it's a good idea to rely on function.toString(), but the fact is that some folks do, and istanbul breaks that use case. Would prevent >0 issues to preserve it :)

I found the performance of instrument is different when I upgrade istanbul from 0.x to 1.x (and I also tried nyc which is same).

I have pushed my test code to https://github.com/popomore/istanbul-instrument, you can run node test.js to see the result.

[email protected] and nyc are using istanbul-lib-instrument to instrument code depending on babylon, but [email protected] is using esprima. Is that mean babylon is slower than esprima?

The clover xml report (generated via nyc report --reporter=clover) appears to be invalid.
Please consider clover.zip.

The following snippet illustrates the problems:

<coverage generated="1490037667659" clover="3.2.0">
  <project timestamp="1490037667660" name="All files">
    <metrics statements="446" coveredstatements="442" conditionals="278" coveredconditionals="264" methods="78" coveredmethods="78" elements="802" coveredelements="784" complexity="0" loc="446" ncloc="446" packages="1" files="9" classes="9">
      <file name="apk.js" path="/home/travis/build/testspace-open/dockerfilelint/lib/apk.js">
...
    </metrics>
  </project>
</coverage>

• the top level metrics has to be "inline" (i.e. has no children) but instead it wraps the whole content
• the content has to be wrapped in package tag

Expected output:

<coverage generated="1490037667659" clover="3.2.0">
  <project timestamp="1490037667660" name="All files">
    <metrics statements="446" coveredstatements="442" conditionals="278" coveredconditionals="264" methods="78" coveredmethods="78" elements="802" coveredelements="784" complexity="0" loc="446" ncloc="446" packages="1" files="9" classes="9"/>
    <package name="lib">
      <file name="apk.js" path="/home/travis/build/testspace-open/dockerfilelint/lib/apk.js">
...
    </package>
  </project>
</coverage>

Istanbul seems to be heavily promoting nyc, which is awesome because nyc is great. But it's also just the CLI. Just as often, devs will need to use the programmatic CLI. The programmatic CLI seems to be in this repo, but the README here states:

You're probably actually looking for one of the following repos:

This might not be true, though, given how frequently devs use programmatic APIs, too. The new website (which is awesome, by the way!) also only has CLI information, without any programmatic APIs documented.

Jest, for instance, is a popular library that uses the istanbul-api lib to use the programmatic API. This is a good demonstration of its utility, I think.

Does the istanbul team have any plans to document/promote programmatic usage of istanbul as well as the new CLI? I think the community would really appreciate it, as well as benefit from it!

Thanks for reading ✌️