Ts-jest: What does the new major release of Jest (24) means for this library

Created on 28 Jan 2019 · 37Comments · Source: kulshekhar/ts-jest

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

Discussion

Source

rluvaton

👍18

Most helpful comment

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

kulshekhar on 28 Jan 2019

👍36

All 37 comments

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?

lychyi on 28 Jan 2019

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

jrr on 28 Jan 2019

❤4

kulshekhar on 28 Jan 2019

👍36

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

rluvaton on 28 Jan 2019

👍3

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

kulshekhar on 29 Jan 2019

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

Bnaya on 29 Jan 2019

👍3

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:

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)
The problem that you describe about running TSC before Babel will be fixed
ts-jest will continue to live (somehow)

rluvaton on 30 Jan 2019

👍2

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.

GeeWee on 30 Jan 2019

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?

fgrandel on 8 Feb 2019

👍17

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..

kirillgroshkov on 9 Feb 2019

👍4

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

artola on 13 Feb 2019

👍1

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

kirillgroshkov on 13 Feb 2019

@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

kulshekhar on 13 Feb 2019

👍4

@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.

artola on 13 Feb 2019

👍2

@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?

kirillgroshkov on 13 Feb 2019

👍1

It looks like bumping the version was attempted in https://github.com/kulshekhar/ts-jest/pull/957 but the builds failed

mdlavin on 13 Feb 2019

Did a quick PR here: https://github.com/kulshekhar/ts-jest/pull/973
Let's see if my naive approach of just bumping versions will work... Tests passed, at least.:)

kirillgroshkov on 14 Feb 2019

👍2 🎉1

@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?

artola on 14 Feb 2019

👍19 👀5

@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).

kulshekhar on 14 Feb 2019

❤5

+1. Please do it! :)

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

ivanfilhoz on 14 Feb 2019

looking at this now

kulshekhar on 14 Feb 2019

👍7

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

kulshekhar on 15 Feb 2019

Is there any success?

JustFly1984 on 18 Feb 2019

@JustFly1984 Watch #957

yumetodo on 18 Feb 2019

@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.

https://github.com/kulshekhar/ts-jest/blob/1ac501ac52986c0f143900c2a441f472666f4991/src/config/config-set.ts#L348

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.

artola on 20 Feb 2019

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

Jessidhia on 21 Feb 2019

❤3

@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 https://github.com/kulshekhar/ts-jest/pull/960#issuecomment-464074343

artola on 21 Feb 2019

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.

toolness on 28 Feb 2019

👍2

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 on 28 Feb 2019

👍1

@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.?

shercoder on 6 Mar 2019

@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.

kulshekhar on 7 Mar 2019

👀3

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

ahnpnl on 2 Mar 2020

Possibly, some discussion in https://github.com/azz/jest-runner-tsc/issues/20

SimenB on 2 Mar 2020

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.

kirillgroshkov on 2 Mar 2020

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 https://github.com/kulshekhar/ts-jest/issues/1115

ahnpnl on 2 Mar 2020

… 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.