nyc: Problems with --all

Background

I’m using TypeScript with Jasmine. The only way I figured out how to get nyc to work with Jasmine was to point Jasmine at the transpiled tests. Using sourceMap, the coverage report looks good until I add "all: true" in my nyc config.

Tests are run using npm test which runs nyc jasmine. The nyc config in package.json looks like:

  "nyc": {
    "all": true,
    "extension": [
      ".ts"
    ],
    "include": [
      "dist/src/**/*"
    ]
  }

Expected Behavior

I would expect both the files loaded in tests and the files without any coverage to be mapped to their TypeScript source.

Observed Behavior

The files which aren’t loaded by tests report their JS versions instead of the TS versions I’d expect. The files being loaded in tests still report against the TS version.

Bonus Points! Code (or Repository) that Reproduces Issue

I can’t share the repo, but if this is being a problem to recreate I could create a dummy repo with the same setup.

Forensic Information

Operating System: Ubuntu 16.04 Environment Information: sh -c ‘node --version; npm --version; npm ls’ > output.txt https://gist.github.com/marshmellow1328/b086ec34ac8ea8521c23bed60ed59329

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 4
Comments: 18 (5 by maintainers)

Most upvoted comments

I’m using TypeScript with Jasmine like @marshmellow1328 and @SanderDeWaal1992 and the coverage reports are reliably correct with --all if I turn off source map caching:

nyc --all --cache=false jasmine

Notice that I don’t include --extension .ts. This extra configuration is unnecessary assuming you compile your TypeScript (including source maps) before running nyc.

TypeScript version: 3.0.1 Node version: 8.11.4 NYC version: 13.1.0

mheggeseth on Jan 3, 2019

We’re experiencing a similar issue. When adding "all": true to our .nycrc, code coverage report generation exhibits non-deterministic behavior - sometimes it reports the correct numbers and correct source mappings, sometimes numbers and source mappings are off, roughly in 50% of the cases.

Sometimes it’s correct:

… and sometimes it’s wrong:

While some files that have 100% coverage suddenly start reporting lower coverage values and wrong source mappings, other files that are part of the report still report correct numbers and source mappings. When we remove "all": true, coverage reports are correct 100% of the time. This is how we invoke our tests (TypeScript):

$(npm bin)/nyc $(npm bin)/ts-node --require tsconfig-paths/register tests/index.ts

Our current “solution” is to remove "all": true.

squidfunk on Mar 29, 2018

@ciekawy --all will not work properly if ts-node/register is required at the mocha level rather than the nyc level, because when nyc requires files it won’t understand the TypeScript syntax.

This might be a good starting point for debugging your projects, if you’re finding you’re unable to have nyc instrument the require statement.

bcoe on Aug 1, 2017

@ciekawy @bcoe could you share your set up for ts/node/register. I’m getting empty coverage using --all and the tool works randomly in different machines using the same set up.

juanpicado on Oct 2, 2017

currently I’m able to run ts-node/register on mocha level rather than with nyc (as otherwise running pure mocha without nyc won’t work).

ciekawy on Jul 31, 2017