What does the new major release of Jest (24) means for this library

[rluvaton]

What does the new major release of Jest (version 24) mean to this library?

In the Jest announcement for version 24 was written:

the next major release of Jest - version 24! ... Highlights include built-in support for TypeScript by upgrading the Jest internals to Babel 7

[lychyi]

This is a good question, I have the same one as well. I'm getting peer dependency warnings but so far it works with Jest 24. The 24 docs also state:

If you want to run typechecks while you test, you should use ts-jest

So it doesn't seem like it replaces ts-jest entirely?

[jrr]

This page, linked from the readme, outlines some other shortcomings of Babel's support; I wonder if these are still accurate?

https://kulshekhar.github.io/ts-jest/user/babel7-or-ts

[kulshekhar]

To be entirely honest, I think (and hope) that this is the start of something that ends with native typescript support in Jest. There's a good chance of that given that Jest itself is moving away from flow to use ts.

Even in its current state, I think using typescript via babel should be the way to go for testing. Type-checking should be separate from testing and tsc can be used for that directly. There's no benefit in having the test runner also do the type-checking.

I know this isn't a universally shared opinion (we've had disagreements even amongst the contributors here on this) so I'll try to do what needs to be done to add Jest 24 support in ts-jest via a new version as soon as I can set aside a few hours (or a day) for this

[rluvaton]

Is it possible that ts-jest will merge with jest itself?

[kulshekhar]

I think it'd be more like ts-jest being rendered redundant

[Bnaya]

There are some limitations for babel7 TS transpilation, that, for the near future (I hope only for the near),
That requires to run TSC before babel in some cases. (tsconfig isolatedModule must be true, re export interfaces not working, decelerations: true not working).
(not to mention more legacy typescript features)

Until we will have a way to overcome these limitations, ts-jest or other setup that runs tsc before babel is a must

[rluvaton]

There are some limitations for babel7 TS transpilation, that, for the near future (I hope only for the near),
That requires to run TSC before babel in some cases. (tsconfig isolatedModule must be true, re export interfaces not working, decelerations: true not working).
(not to mention more legacy typescript features)

Until we will have a way to overcome these limitations, ts-jest or other setup that runs tsc before babel is a must

This is time limited advantage to this library, but sooner or later they will implement it.

So my suggestion is that jest and ts-jest will merge

This will have some advantages:

1. The move to TS will be quicker with the help of this team that have knowledge of jest with TS (because this is the purpose of this library)
2. The problem that you describe about running TSC before Babel will be fixed
3. ts-jest will continue to live (somehow)

[GeeWee]

Some things are probably never going to be possible using Babel to transpile Typescript. The only one I doubt we'll actually see fixed is decoratorMetadata - the other one is const enum, but I know that this can potentially be transpiled by babel, but isn't right now.

[ghost]

In the meantime: Does it make sense to bump the peer dependency to 24 to get rid of the warning message as ts-jest seems to work just fine with jest v24?

[kirillgroshkov]

Yes, came here with same question - is it possible to disable ts-jest warning about "unsupported Jest 24"? It works just fine for all my projects, but warning is annoying..

[artola]

@kulshekhar Could be possible to release a package to support v24 (peerDependencies)? It seems that everything is ok, just to remove annoying warnings.

[kirillgroshkov]

Exactly. And if it's discovered that something is broken - people will open another issue:)

[kulshekhar]

@artola sure, if it works, I'd be happy to merge in a quick PR for this

@kirillgroshkov

Exactly. And if it's discovered that something is broken - people will open another issue:)

It's just that I haven't been able to find time for this and I was a bit hesitant to do something that could give users a false sense of security

[artola]

@kirillgroshkov Internal tests and CI are there for a very good reason, if they run properly means that as far as we can and known, it is safe to go on.

[kirillgroshkov]

@artola sure, if it works, I'd be happy to merge in a quick PR for this

Oh, great! Someone want to do such quick PR?

[mdlavin]

It looks like bumping the version was attempted in #957 but the builds failed

[kirillgroshkov]

Did a quick PR here: #973
Let's see if my naive approach of just bumping versions will work... Tests passed, at least.:)

[artola]

@kirillgroshkov @kulshekhar Moving to jest v24 also means that jest-config starts to use babel-jest v24.

My tests break with the following error:

  ● Test suite failed to run

    Passing cached plugin instances is not supported in babel.loadPartialConfig()

      at forEach.item (node_modules/@babel/core/lib/config/partial.js:120:13)
          at Array.forEach (<anonymous>)
      at loadPartialConfig (node_modules/@babel/core/lib/config/partial.js:118:27)
      at TsJestTransformer.process (node_modules/ts-jest/dist/ts-jest-transformer.js:110:32)

@kulshekhar some hint how to solve it?

[kulshekhar]

@artola I'm not sure off the top of my head. I also think that #957 would be the proper way to update jest if that PR can be updated to pass tests.

I'm at work at the moment and will try to take a look at this and the PR later today (if I can finish up on time, in 5-6 hours).

[ivanfilhoz]

+1. Please do it! :)

Using with Jest 24 (for typechecking on tests) and everything is fine here.

[kulshekhar]

looking at this now

[kulshekhar]

I've pushed a commit on #957 which should hopefully get things moving. Big caveat - I haven't reviewed the rest of the PR

[JustFly1984]

Is there any success?

[yumetodo]

@JustFly1984 Watch #957

[artola]

@thymikee @kulshekhar Regarding the issue with babel and the cached config Passing cached plugin instances is not supported in babel.loadPartialConfig(), I found that if we return config = {}; in this line ... then everything goes fine, no error.

ts-jest/src/config/config-set.ts

Line 348 in 1ac501a

config = loadOptions(base) as BabelConfig

I hope that this is the tip of the iceberg, but for sure it is not a fix, neither I have a complete understanding of of the other conditions around this block.

[Jessidhia]

the solution is to call loadPartialConfig().options, and not to call loadOptions().

See https://github.com/babel/babel/blob/master/packages/babel-core/src/config/index.js and https://github.com/babel/babel/blob/master/packages/babel-core/src/config/partial.js

[artola]

@Jessidhia @kulshekhar Your are right, with config = loadPartialConfig(base).options; the error message is gone too.

What should be done here? because your PR #960 also contains this comment from @SimenB #960 (comment)

[toolness]

For anyone reading this thread who is considering migrating to Babel's built-in TypeScript support, aside from the points mentioned in the aforementioned blog post, there's also a major bug in the Jest integration, which is that TS shorthand class properties using super() lead to invalid code when test coverage (Istanbul) is enabled. Tracing this problem to Jest's test coverage took me a really long time so I'm hoping posting about it here will help others figure it out quicker than I did.

To clarify, this problem is with Babel's built in TS support, not with ts-jest. I'm just posting this here for anyone who, like me, is considering migrating due to the Passing cached plugin instances is not supported in babel.loadPartialConfig() error mentioned above.

[SimenB]

To be entirely honest, I think (and hope) that this is the start of something that ends with native typescript support in Jest. There's a good chance of that given that Jest itself is moving away from flow to use ts.

We have no plans to include type checking in Jest (TS, Flow or otherwise). If anything around type checking would happen inside of Jest, it would be enabling runners like https://github.com/azz/jest-runner-tsc to be as good a solution it can be (e.g. allowing it to spin up a TS server once it can query instead of doing file by file etc.).

Even in its current state, I think using typescript via babel should be the way to go for testing. Type-checking should be separate from testing and tsc can be used for that directly. There's no benefit in having the test runner also do the type-checking.

I personally agree with this, but I also very much understand those that think tests should be type checked before they are run. So I think there'll always be a place for ts-jest.

---

Any concrete proposals for changes we can make in Jest that would simplify ts-jest's implementation (or make its advantages available to other transformers more easily) is very much welcome of course!

[shercoder]

@kulshekhar We are upgrading to react-native 0.58., and basically we are having to get rid of the usage of namespace in our code base because of babel7 to get our tests working. Is there a way to continue to use ts-jest with RN 0.58.?

[kulshekhar]

@shercoder it's hard for me to answer that as I don't know what parts of ts-jest need to be updated to get this working. I'm actively trying to find a window of a couple of days to

• understand what needs to be done, and
• implement that

to bring ts-jest up to speed. I haven't been able to find this kind of a window for a while now but hope I'll be able to soon.

[ahnpnl]

To be entirely honest, I think (and hope) that this is the start of something that ends with native typescript support in Jest. There's a good chance of that given that Jest itself is moving away from flow to use ts.

We have no plans to include type checking in Jest (TS, Flow or otherwise). If anything around type checking would happen inside of Jest, it would be enabling runners like https://github.com/azz/jest-runner-tsc to be as good a solution it can be (e.g. allowing it to spin up a TS server once it can query instead of doing file by file etc.).

Even in its current state, I think using typescript via babel should be the way to go for testing. Type-checking should be separate from testing and tsc can be used for that directly. There's no benefit in having the test runner also do the type-checking.

I personally agree with this, but I also very much understand those that think tests should be type checked before they are run. So I think there'll always be a place for ts-jest.

Any concrete proposals for changes we can make in Jest that would simplify ts-jest's implementation (or make its advantages available to other transformers more easily) is very much welcome of course!

@SimenB maybe can separate type checking into another node process ? See https://github.com/microsoft/TypeScript/wiki/Performance#concurrent-type-checking

[SimenB]

Possibly, some discussion in azz/jest-runner-tsc#20

[kirillgroshkov]

Actually, we disable type-checking when running ts-jest (diagnostics=false), for performance. And do yarn tsc -P tsconfig.test.json before running all tests. It seems to be faster - to compile whole project (all tests) at once with tsc.

That's what we do in CI. In local development we're ok to ignore type errors in tests, cause either they can be caught at a later stage, or tests will fail anyway because something is undefined/missing.

[ahnpnl]

Actually, we disable type-checking when running ts-jest (diagnostics=false), for performance. And do yarn tsc -P tsconfig.test.json before running all tests. It seems to be faster - to compile whole project (all tests) at once with tsc.

Yes definitely compiling before running all tests is faster since it is sequence task. When running tests with typescript LanguageService, ts-jest does 2 things in the same node process: emit and type checking which type checking might block emit or vice versa. So I was thinking about separating type checking into another node process like fork-ts-checker-webpack-plugin does.

If anyone has more ideas about improving performance for ts-jest, feel free to contribute 👍 Related discussion in #1115

[slikts]

… I also very much understand those that think tests should be type checked before they are run. So I think there'll always be a place for ts-jest.

Is this expanded on somewhere? I've not been able to understand the benefits of type checking in a test runner (particularly the errors not being filterable by Jest) outside of possible familiarity. It runs counter to the common iterative/exploratory/tinkering workflow with short feedback loops. It's why, for example, linter errors would typically break a production build but not a development server. What ultimately matters is that the code with errors isn't merged, but the developer should be able to make the call to ignore it while developing.