Ts-jest: 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 ?

[drrnkin]

@ncgreco1440 the comment on that babel configuration link seems to negate the reason for this ticket -- I need type checking to work in jest tests.

Because TypeScript support in Babel is transpilation, Jest will not type-check your tests as they are run. If you want that, you can use ts-jest.

[drrnkin]

@ahnpnl thank you for the fix! As this is my first time logging a bug in an npm package, can you say what version will contain the fix and when it will be available? i.e. how long until https://www.npmjs.com/package/ts-jest is updated?

[ahnpnl]

the fix will be in the next release version. Please wait :)

Note: watch mode fix isn't included in the fix for this issue. Watch mode seems to be more complex to come up with the fix. For watch mode, please follow #943 for the update.

cc @kulshekhar

[kulshekhar]

I'll try to publish a new version tomorrow

[drrnkin]

Thank you. Not trying to rush anyone, just unclear on how the next steps take place. I'll keep a watch out for the next release.

[ahnpnl]

hi @drrnkin @ncgreco1440 @tairosonloa @angeloocana would you please help us to test the watch mode fix ? You can download tgz file here and install it. Remember to clear cache before you run your tests.

Can you please try the fix too @kulshekhar ?

[drrnkin]

@ahnpnl I can confirm that the bug is fixed in the latest ts-jest! I used the latest from https://www.npmjs.com/package/ts-jest rather than the tgz file since it was updated hours ago.

My only changes from the original zip content was to upgrade jest and ts-jest to latest (I realize the jest upgrade isn't the important part).

    "jest": "^25.2.4",
    "ts-jest": "^25.3.0",

Thanks!

[ahnpnl]

25.3.0 doesn’t have watch mode fix actually. My tgz file contains fixes for watch mode :) but I need more help to test it before I make a PR

[drrnkin]

Sounds like a different but related bug. This bug is fixed. Are the repro steps for what you want to to test the same as this one, except in watch mode?

[ahnpnl]

Yes the repro steps are mostly the same but in watch mode. Please try to break it :)

[drrnkin]

OK, your fix looks good in watch mode. Starting with the original zip file (but upgraded to 25.3.0), I verified that running yarn test --watchAll failed to detect changes in watch mode as expected.

• I emptied node_modulests-jest and spliced in the contents from the tgz file.
• Removed the jestCache folder
• Ran yarn test --watchAll
• Messed around altering the Thing type, even deleting it, and then restoring it.
• At all points correct reports were given.

LGTM :-)

[ahnpnl]

Thanks, hopefully hearing from others too

[ncgreco1440]

So far it seems to do the job. I made a new test which attempts to dereference an invalid property on a class. Once the test suite runs, I see a failure as expected. Upon making a change to the source code and waiting for the test suite to rerun ts-jest now properly sees the newly create property in the class and the test passes as expected.

I ran jest with --watch and --watchAll same results.

[drrnkin]

This appears to have regressed. The problem appears to be back with the exact same repro steps except for using [email protected] (and jest 26.x).

Can this be re-opened? I don't have permission to do so.