Ts-jest: Not generating remapped with jest ^18.1.0

[japhar81]

I just updated my project to jest@^18.1.0 and ts-jest@^18.0.0, and suddenly my coverage isn't creating a remapped directory. This was working fine with jest@^17.0.3 and ts-jest@^17.0.0. The only change has been version updates.

package.json:

"jest": "^18.1.0",
"ts-jest": "^18.0.0",

and my config;

{
  "globals": {
    "__TS_CONFIG__": "./src/client/tsconfig.json"
  },
  "moduleFileExtensions": [
    "ts",
    "tsx",
    "js"
  ],
  "transform": {
    ".(ts|tsx)": "./node_modules/ts-jest/preprocessor.js"
  },
  "testResultsProcessor": "./node_modules/ts-jest/coverageprocessor.js",
  "testRegex": "src/client/.*\\.spec\\.(ts|tsx|js)$",
  "collectCoverage": true,
  "collectCoverageFrom": [
    "src/client/**/*.{js,ts,tsx}",
    "!src/client/index.*",
    "!**/node_modules/**"
  ],
  "coverageReporters": ["text", "html"]
}

[kulshekhar]

Would it be possible for you to create a minimal repo that reproduces this issue?

[japhar81]

It's not quite minimal, but clone https://github.com/japhar81/redux_apigw -- npm install && npm run client:test will show the behavior.

[kulshekhar]

A minimal repo helps focus debugging efforts and minimizes the chances of getting lost in unrelated code. That's why it's very helpful in getting issues resolved quickly. As an example, whenever someone shares a minimal repo, I can take a look at it as soon as I have a 5-10 minute window.

What you've shared is obviously the next best thing but I'll only be able to test that when I can carve out a larger time window

[japhar81]

I can try to strip it down, but most of the heft is from making TS work, im not sure it'll actually simplify. I do suspect this change in jest is the problem;

+* Properly resolve `snapshotSerializers`, `setupFiles`, `transform`, `testRunner` and `testResultsProcessor` instead of using `path.resolve`.

Reason i say that is I added a console.log in coverageprocessor.js right after function processResult(result) { and it looks like processResult isn't getting invoked at all.

[kulshekhar]

are you using --no-cache?

[japhar81]

yes indeed: ./node_modules/.bin/jest --config ./jest.client.json --no-cache

[rfgamaral]

I have the same issue too, downgrading Jest worked for me. This is probably the same issue as #104.

[japhar81]

Ok, I've been digging more.. https://github.com/kulshekhar/ts-jest/blob/master/src/preprocessor.ts#L18 is getting undefined for testResultsProcessor. Not sure why yet.

[japhar81]

I can't explain this, but while trying to debug, i discovered that --runInBand solves it for some reason?

[kulshekhar]

I'm hoping that once facebook/jest#2290 is done, ts-jest will be able to leverage that for more reliable coverage reports. That will probably address a lot of coverage related issues that are currently open!

[kulshekhar]

I've just upgraded ts-jest to use the latest version of jest (19.0.0). In the process, I came across a similar issue and fixed it. Can you please check if the latest version resolves this issue?

[japhar81]

[email protected], @types/[email protected],[email protected] -- works fine with --runInBand, but no remapped directory without --runInBand

[bumbleblym]

i have the same experience as @japhar81; remapped directory is only generated with --runInBand on jest/[email protected]

[rfgamaral]

I've updated my packages:

npm list --depth 0 | grep jest
+-- @types/[email protected]
+-- [email protected]
+-- [email protected]

And I'm still having issues.

@kulshekhar I can't get a minimal repo working but I can give you access to my private repo (it's a small project) demonstrating this problem if you're interested.

[kulshekhar]

@rfgamaral I'm seriously considering rewriting the entire thing because there are parts of ts-jest, like coverage, that I'm not familiar with (these were contributed by the community).

The only problem I'm facing is shortage of time :(

I do have this issue on my list of things to do so when I get around to it, I'll ping you for access. Would that be fine?

[rfgamaral]

@kulshekhar Yeah, no problem, whenever you need :)

[bumbleblym]

don't think i can minimze my repro any further.

it has 2 files/tests; running npm run test:series (with the jest -i flag) generates the remapped folder, while npm run test does not.

you can also reproduce the issue by having an empty index.ts, and a.test.ts/b.test.ts containing just:

import '.'
it('', () => {})

, though this might be an unrelated pathological case.

[japhar81]

@kulshekhar I'm close to a fix, but I can not find a way to test effectively.. do you have a workflow you use to debug this somehow? I can't figure out how to debug ts-jest when its being invoked by jest. If I could get some breakpoints I'd have a PR ready in no time.. console.log is not a great way to do this.. any suggestions?

[kulshekhar]

@japhar81 tbh, I'm not very familiar with the part that does coverage (I don't use coverage). I'm trying to find a couple of days of time where I can look at the entire thing and see if it can be better implemented to use the new change in jest!

[japhar81]

Here's the problem; when not using --runInBand jest uses worker-process. When it does, the argv ts-jest sees here: https://github.com/kulshekhar/ts-jest/blob/master/src/utils.ts#L10 is actually;

["/usr/local/Cellar/node/7.2.1/bin/node","./node_modules/worker-farm/lib/child/index.js"]

so it can't find the config.

[japhar81]

@kulshekhar its not the coverage thats the problem :) It's actually the worker-process and getting the jest config. Coverage just happens to be the symptom. I'm willing to bet it's not actually reading my config for tsconfig.json location either. I suspect we need to find a different way to read the config.

[kulshekhar]

@japhar81 if you're sure about this, should we track this in a new issue?

[japhar81]

@kulshekhar I'm pretty confident, but i want to do a bit more digging. The lack of debugging options beyond console.log is really killing me on this one

[japhar81]

@kulshekhar PR is in for a fix -- https://github.com/kulshekhar/ts-jest/pull/132

[kulshekhar]

Fixed by #132