Ts-jest: (Ts)-Jest should ignore d.ts files in coverage tests

[jsamr]

Issue

In --coverage mode, ts-jest attempts to cover module type declaration files (*.d.ts) which results in an error (see bellow). Seems related to #136

error stack

Failed to collect coverage from <rootDir>/src/dummy.d.ts
ERROR: Error: Debug Failure. False expression: Output generation failed
STACK: Error: Debug Failure. False expression: Output generation failed
at Object.transpileModule (<rootDir>/node_modules/typescript/lib/typescript.js:86543:18)
at Object.process (<rootDir>/node_modules/ts-jest/dist/preprocessor.js:22:32)
at ScriptTransformer.transformSource (<rootDir>/node_modules/jest-runtime/build/script_transformer.js:218:35)
at exports.default (<rootDir>/node_modules/jest/node_modules/jest-cli/build/generate_empty_coverage.js:32:5)
at module.exports (<rootDir>/node_modules/jest/node_modules/jest-cli/build/reporters/coverage_worker.js:52:94)
at handle (<rootDir>/node_modules/worker-farm/lib/child/index.js:44:8)
at process.<anonymous> (<rootDir>/node_modules/worker-farm/lib/child/index.js:51:3)
at emitTwo (events.js:126:13)
at process.emit (events.js:214:7)
at emit (internal/child_process.js:772:12)

Expected behavior

ts-jest should ignore module type declaration files (*.d.ts) in coverage tests. Those files are only relevant for type checking and are not transpiled to executable code. Thus they are irrelevant for code coverage.

MWE

ts-jest-d-ts-bug

[kulshekhar]

ts-jest doesn't handle anything related to coverage at all. That's handled by Jest. Moreover, given that jest has the coveragePathIgnorePatterns (as you pointed out) which allows ignoring these files, I'm not sure that hard-coding this behavior would be a very good idea.

[jsamr]

@kulshekhar I get your point. Perhaps, at least the error should not show up. It also occurs with a ts source file that only export types / interfaces.

[kulshekhar]

Perhaps, at least the error should not show up

Does the error still show up after setting coveragePathIgnorePatterns?

It also occurs with a ts source file that only export types / interfaces.

This doesn't sound right and probably shouldn't be happening. Is this behavior exhibited in the repo you've linked to?

[jsamr]

Does the error still show up after setting coveragePathIgnorePatterns?

setting coveragePathIgnorePatterns does work :-)

This doesn't sound right and probably shouldn't be happening. Is this behavior exhibited in the repo you've linked to?

I could not reproduce unfortunately ; perhaps it was in watch mode and I just renamed, so I guess this is not an issue.

However I am experiencing an other issue with modules only exporting types:

The coverage wrongly sets Stmts and Lines to 0, which ends up in miscalculation of coverage summary. You can reproduce by cloning the MWE and renaming dummy.d.ts to dummy-err.ts !

[GeeWee]

If the typescript only export types, isn't it transpiled to "nothing" essentially? It makes sense to me that it has 0 lines, but I guess it should also have 100% coverage on those lines.

[GeeWee]

Is this new issue the same as #378?

[jsamr]

@GeeWee Yes somehow this issue splited in two and the second one clearly refers to #378. What do you think of excluding d.ts files by default in coverage mode ?

[GeeWee]

It might be the solution. Is the original issue fixed here? In that case I think we should close this and move the discussion to #378

[kulshekhar]

The coverage wrongly sets Stmts and Lines to 0, which ends up in miscalculation of coverage summary. You can reproduce by cloning the MWE and renaming dummy.d.ts to dummy-err.ts

As @GeeWee pointed out, types/interfaces transpile to nothing so the result doesn't seem wrong. How does coverage treat an empty javascript file?

What do you think of excluding d.ts files by default in coverage mode ?

Given that this can be achieved by configuring the jest regexes to process files, I'm not sure hard-coding the behavior in is a very good idea

[GeeWee]

Closing this in favour of #378