With cached results, changes to type definitions are not detected

[drrnkin]

Issue :

Given a type declaration in core code, and a reference to that type definition in jest code, type-safety is not always enforced.

Expected behavior :

Changes to type definitions should be detected (failing to compile where appropriate).

Minimal repo :

1. Unzip the attached zip file and run yarn and then yarn test (should succeed).
2. Change the type definition in thing.ts to contain b: number
3. Run yarn test again. Due to the cache, it succeeds and should not. It will (correctly) fail if you remove the cache folder "jestCache"

thing.ts contains:

export type Thing = {
	a: number;
	// b: number;
};

thing.test.ts contains:

export const thing: Thing = { a: 1 };

jestCache.zip

[angeloocana]

I also have the same issue, it is so annoying, we had to disable the cache to prevent errors.
Please fix this issue.

[ahnpnl]

Does it happen to watch mode as well ?

[drrnkin]

Yes, the problem still occurs in watch mode. I removed the cache, then (with the code in the initial valid state) I ran yarn test --watchAll (success as expected) . Then I changed the type definition, and jest re-ran the test but it still passed (ie. it failed to detect the compile error).

[ahnpnl]

Thanks, that confirms my suspicion about the same problem with watch mode as well.

[tairosonloa]

We are workarounding this issue by passing --no-cache flag to jest

[drrnkin]

@tairosonloa yes, that's the workaround we're using too, but it makes our test suite jump from about 3 minutes to about 8 minutes, and we run it frequently.

[tairosonloa]

Yeah @drrnkin, I know that feeling too. I posted it because we were having some issues with errors in our tests, that were detected in CI but not in our local development environment.

[ahnpnl]

a bit similar to #943, in the same area

[ncgreco1440]

Running into the same issue here. Using --no-cache doesn't alleviate the issue for me. The only out for me was to just not use ts-jest at all. And fall back to jest's babel configuration as described here.

[ahnpnl]

I’m interested into the case when no cache doesn’t solve the issue. Would you please provide the reproduce repo @ncgreco1440 ?