Support jest 24.9.0 #1315

ChrisLahaye · 2019-12-11T14:05:16Z

Hello,

Jest released a new minor version 24.9.0 that breaks ts-jest. It breaks for prior versions as well due to unconstrained nested dependencies.

The BREAKING change is jestjs/jest@1d8245d#diff-4ac32a78649ca5bdd8e0ba38b7006a1e

Overwriting the nested dependencies confirms this and can be used as temporary workaround:

diff --git a/package.json b/package.json
index ab476e41..37cdc746 100644
--- a/package.json
+++ b/package.json
@@ -78,7 +78,7 @@
     "eslint-plugin-import": "^2.19.1",
     "gulp": "^4.0.2",
     "gulp-typescript": "^5.0.1",
-    "jest": "^24.9.0",
+    "jest": "24.8.0",
     "mongo-seeding": "^3.3.0",
     "mongodb-memory-server": "^6.0.2",
     "nodemon": "^1.19.4",
@@ -88,6 +88,11 @@
     "ts-node": "^8.5.4",
     "typescript": "^3.7.3"
   },
+  "resolutions": {
+    "@jest/core": "24.8.0",
+    "@jest/transform": "24.8.0",
+    "jest-cli": "24.8.0"
+  },

It would be nice if ts-jest could be made compatible with the latest jest release.

Related issues:

Regenerated lock file for "jest": "24.8.0" without overwrite:

cat yarn.lock | grep '@jest'                                                                                                   :(
"@jest/console@^24.7.1", "@jest/console@^24.9.0":
  resolved "https://registry.yarnpkg.com/@jest/console/-/console-24.9.0.tgz#79b1bc06fb74a8cfb01cbdedf945584b1b9707f0"
    "@jest/source-map" "^24.9.0"
"@jest/core@^24.9.0":
  resolved "https://registry.yarnpkg.com/@jest/core/-/core-24.9.0.tgz#2ceccd0b93181f9c4850e74f2a9ad43d351369c4"
    "@jest/console" "^24.7.1"
    "@jest/reporters" "^24.9.0"
    "@jest/test-result" "^24.9.0"
    "@jest/transform" "^24.9.0"
    "@jest/types" "^24.9.0"
"@jest/environment@^24.9.0":
  resolved "https://registry.yarnpkg.com/@jest/environment/-/environment-24.9.0.tgz#21e3afa2d65c0586cbd6cbefe208bafade44ab18"
    "@jest/fake-timers" "^24.9.0"
    "@jest/transform" "^24.9.0"
    "@jest/types" "^24.9.0"
"@jest/fake-timers@^24.9.0":
  resolved "https://registry.yarnpkg.com/@jest/fake-timers/-/fake-timers-24.9.0.tgz#ba3e6bf0eecd09a636049896434d306636540c93"
    "@jest/types" "^24.9.0"
"@jest/reporters@^24.9.0":
  resolved "https://registry.yarnpkg.com/@jest/reporters/-/reporters-24.9.0.tgz#86660eff8e2b9661d042a8e98a028b8d631a5b43"
    "@jest/environment" "^24.9.0"
    "@jest/test-result" "^24.9.0"
    "@jest/transform" "^24.9.0"
    "@jest/types" "^24.9.0"
"@jest/source-map@^24.3.0", "@jest/source-map@^24.9.0":
  resolved "https://registry.yarnpkg.com/@jest/source-map/-/source-map-24.9.0.tgz#0e263a94430be4b41da683ccc1e6bffe2a191714"
"@jest/test-result@^24.9.0":
  resolved "https://registry.yarnpkg.com/@jest/test-result/-/test-result-24.9.0.tgz#11796e8aa9dbf88ea025757b3152595ad06ba0ca"
    "@jest/console" "^24.9.0"
    "@jest/types" "^24.9.0"
"@jest/test-sequencer@^24.9.0":
  resolved "https://registry.yarnpkg.com/@jest/test-sequencer/-/test-sequencer-24.9.0.tgz#f8f334f35b625a4f2f355f2fe7e6036dad2e6b31"
    "@jest/test-result" "^24.9.0"
"@jest/transform@^24.9.0":
  resolved "https://registry.yarnpkg.com/@jest/transform/-/transform-24.9.0.tgz#4ae2768b296553fadab09e9ec119543c90b16c56"
    "@jest/types" "^24.9.0"
"@jest/types@^24.9.0":
  resolved "https://registry.yarnpkg.com/@jest/types/-/types-24.9.0.tgz#63cb26cb7500d069e5a389441a7c6ab5e909fc59"
    "@jest/transform" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/core" "^24.9.0"
    "@jest/test-result" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/test-sequencer" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/environment" "^24.9.0"
    "@jest/fake-timers" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/environment" "^24.9.0"
    "@jest/fake-timers" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/environment" "^24.9.0"
    "@jest/test-result" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/test-result" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/console" "^24.7.1"
    "@jest/environment" "^24.9.0"
    "@jest/test-result" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/console" "^24.7.1"
    "@jest/environment" "^24.9.0"
    "@jest/source-map" "^24.3.0"
    "@jest/transform" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/console" "^24.9.0"
    "@jest/fake-timers" "^24.9.0"
    "@jest/source-map" "^24.9.0"
    "@jest/test-result" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/test-result" "^24.9.0"
    "@jest/types" "^24.9.0"
    "@jest/types" "^24.9.0"

The text was updated successfully, but these errors were encountered:

ahnpnl · 2019-12-11T14:17:43Z

hi,

Our CI is running with jest 24.9.0 and there aren't any issues. The breaking change you linked doesn't belong to 24.9.0. master jest branch isn't 24.9.0. What exactly not working ?

ChrisLahaye · 2019-12-11T15:16:40Z

@ahnpnl Oops, you are right, I linked the wrong commit.

I use a module in my globalSetup file that performs require on typescript files. Jest 24.9.0 with ts-jest doesn't transpile the import statements correctly.

yarn jest                                                                                                                     :(
yarn run v1.21.0
$ /project/node_modules/.bin/jest
Determining test suites to run...
/project/src/db/seeds/1-users/users.ts:1
import { ObjectId } from '../../../app/helpers/db';
       ^

SyntaxError: Unexpected token {
    at Module._compile (internal/modules/cjs/loader.js:723:23)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)
    at Module.require (internal/modules/cjs/loader.js:692:17)
    at require (internal/modules/cjs/helpers.js:25:18)
    at FileSystem.readFile (/project/node_modules/mongo-seeding/dist/populator/filesystem.js:109:16)
    at paths.reduce (/project/node_modules/mongo-seeding/dist/populator/filesystem.js:92:38)
    at Array.reduce (<anonymous>)
MongoSeedingError: SyntaxError: Unexpected token {
    at wrapError (/project/node_modules/mongo-seeding/dist/index.js:110:19)
    at Seeder.readCollectionsFromPath (/project/node_modules/mongo-seeding/dist/index.js:52:23)
    at globalSetup (/project/src/lib/jest/global-setup.ts:20:32)
    at process._tickCallback (internal/process/next_tick.js:68:7)
error Command failed with exit code 1.

ahnpnl · 2019-12-11T15:18:23Z

would you please provide a minimum repo for your issue ? Thanks 👍

ChrisLahaye · 2019-12-11T15:24:03Z

@ahnpnl Will do tomorrow or the day after tomorrow, thank you

ChrisLahaye · 2019-12-15T14:06:05Z

@ahnpnl https://github.com/ChrisLahaye/js-test-bug

The compilation issues only occur after awaiting a promise in globalSetup:

  await new Promise((resolve): void => {
    setTimeout((): void => {
      resolve('This promise causes compilation issues in require statements by modules');
    }, 400);
  });

Without it, the required files are compiled correctly.

ahnpnl · 2019-12-27T23:09:28Z

hi, it looks strange to me that removing the piece of code await new Promise solved the issue. Have you tried with babel only ? Does it work with only babel and jest ?

dl748 · 2019-12-31T16:37:52Z

I'm getting an issue that seems to be 24.9 related as well.

TypeError: Unable to require '.d.ts' file.

Reverted back to 24.8 and it works just fine.

ts-jest/src/compiler.ts

Line 185 in dd816ab

const output = service.getEmitOutput(fileName)

seems to be returning no output files

ahnpnl · 2019-12-31T16:43:06Z

do you have a repo for your issue @dl748 ?

ChrisLahaye · 2020-01-10T12:29:14Z

hi, it looks strange to me that removing the piece of code await new Promise solved the issue. Have you tried with babel only ? Does it work with only babel and jest ?

That really is the case. You can try the repo with and without the await commented out.

ahnpnl · 2020-01-10T16:39:15Z

Yes I can see the error you encountered @ChrisLahaye
@dl748 your issue is something else, the line of code you link is where language service get fileName. Might be related to symlink in monorepo.

ChrisLahaye · 2020-01-12T09:48:10Z

@ahnpnl My apologies for asking this directly, but could you please help me fix/debug this issue?

ahnpnl · 2020-01-12T10:07:15Z

At the moment I still don’t have a clue about this issue, 1st time for me to see this.

is-equal · 2020-01-16T16:16:55Z

I got the same error as @ChrisLahaye, which is related to transpiling the import statements. The tools I'm using is ts-jest + typeorm. I can't transpile the entities and migrations files on version 24.9.0. I've rollbacked the version to 24.8.0 in other it to work.

ahnpnl · 2020-01-16T16:20:42Z

Is it related to globalSetup async too ?

is-equal · 2020-01-16T16:37:42Z

@ahnpnl yes, globalSetup and globalTeardown.

ahnpnl · 2020-01-22T16:03:27Z

There is a documentation updated for using setTimeout in jest v25.1 in section setupFilesAfterEnv suggesting that using settimeout should be inside setupFilesAfterEnv. See PR

Does jest support setTimeout in globalSetup and globalTeardown ?

ChrisLahaye · 2020-01-22T19:22:20Z

@ahnpnl I just used setTimeout to have the promise resolve after a while. The problem however occurs for any promise, even without setTimeout.

kibertoad · 2020-01-23T07:19:17Z

@kulshekhar is this one redundant now?

ahnpnl · 2020-01-23T07:21:47Z

There is an issue with Promise in globalSetup and globalTearDown seems to be related to 24.9, not sure yet what causes the issue.

kulshekhar · 2020-01-23T07:22:54Z

@kibertoad I'm not sure if this is redundant. If it's still a problem and if jest 24.9.0 is being used, this should be left open until fixed

kibertoad · 2020-01-23T07:27:28Z

Didn't last pr drop support for 2.4?

kulshekhar · 2020-01-23T07:28:19Z

It did but only for v25+. It could, in theory, be that someone wants to keep using v24.x

ahnpnl · 2020-02-03T11:17:30Z

hi @ChrisLahaye , so I spent some times to debug your issue with the repo you provided. Here is the summary of the debugging. Please 1st take a look at how ts-jest works via this diagram.

A few notes on how jest and ts-jest works in general:

jest uses pirate to do something (I don't know) and pirate will deliver the file paths to jest ScriptTransformer, in detail transformSource method is invoked.
Looking at diagram in the documentation, when transformResource is invoked, it will call transformer.process.
transformer.process will call ts-jest process
The flow will continue with ts-jest diagram in the documentation.
In both error case and successful case, compiled global-setup.ts source is the same.

So what is the difference between the successful case vs error case

When commenting out the `setTimeout` piece of codes (successful case)

pirate delivers 3 or more file paths to jest, and then jest uses those file paths to invoke ts-jest transformer via ScriptTransformer.

When uncommenting the `setTimeout` piece of codes (error case)

pirate only delivers 1 single file path to jest, and then jest uses that only single file path to invoke ts-jest transformer via ScriptTransformer.

Conclusion

My conclusion from the debugging is this is not ts-jest issue. Because ts-jest receives only 1 file path from ScriptTransformer (which is jest internal code) in the error case. I think this is caused by jest rather than ts-jest.

ahnpnl · 2020-03-24T17:31:18Z

Close as duplicate #1391

ahnpnl added the 💬 Question label Feb 4, 2020

ahnpnl closed this as completed Mar 24, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support jest 24.9.0 #1315

Support jest 24.9.0 #1315

ChrisLahaye commented Dec 11, 2019 •

edited

ahnpnl commented Dec 11, 2019

ChrisLahaye commented Dec 11, 2019 •

edited

ahnpnl commented Dec 11, 2019

ChrisLahaye commented Dec 11, 2019

ChrisLahaye commented Dec 15, 2019

ahnpnl commented Dec 27, 2019

dl748 commented Dec 31, 2019 •

edited

ahnpnl commented Dec 31, 2019

ChrisLahaye commented Jan 10, 2020

ahnpnl commented Jan 10, 2020

ChrisLahaye commented Jan 12, 2020

ahnpnl commented Jan 12, 2020

is-equal commented Jan 16, 2020

ahnpnl commented Jan 16, 2020

is-equal commented Jan 16, 2020 •

edited

ahnpnl commented Jan 22, 2020

ChrisLahaye commented Jan 22, 2020

kibertoad commented Jan 23, 2020

ahnpnl commented Jan 23, 2020

kulshekhar commented Jan 23, 2020

kibertoad commented Jan 23, 2020

kulshekhar commented Jan 23, 2020

ahnpnl commented Feb 3, 2020

ahnpnl commented Mar 24, 2020

Support jest 24.9.0 #1315

Support jest 24.9.0 #1315

Comments

ChrisLahaye commented Dec 11, 2019 • edited

ahnpnl commented Dec 11, 2019

ChrisLahaye commented Dec 11, 2019 • edited

ahnpnl commented Dec 11, 2019

ChrisLahaye commented Dec 11, 2019

ChrisLahaye commented Dec 15, 2019

ahnpnl commented Dec 27, 2019

dl748 commented Dec 31, 2019 • edited

ahnpnl commented Dec 31, 2019

ChrisLahaye commented Jan 10, 2020

ahnpnl commented Jan 10, 2020

ChrisLahaye commented Jan 12, 2020

ahnpnl commented Jan 12, 2020

is-equal commented Jan 16, 2020

ahnpnl commented Jan 16, 2020

is-equal commented Jan 16, 2020 • edited

ahnpnl commented Jan 22, 2020

ChrisLahaye commented Jan 22, 2020

kibertoad commented Jan 23, 2020

ahnpnl commented Jan 23, 2020

kulshekhar commented Jan 23, 2020

kibertoad commented Jan 23, 2020

kulshekhar commented Jan 23, 2020

ahnpnl commented Feb 3, 2020

So what is the difference between the successful case vs error case

When commenting out the setTimeout piece of codes (successful case)

When uncommenting the setTimeout piece of codes (error case)

Conclusion

ahnpnl commented Mar 24, 2020

ChrisLahaye commented Dec 11, 2019 •

edited

ChrisLahaye commented Dec 11, 2019 •

edited

dl748 commented Dec 31, 2019 •

edited

is-equal commented Jan 16, 2020 •

edited

When commenting out the `setTimeout` piece of codes (successful case)

When uncommenting the `setTimeout` piece of codes (error case)