upgrade ts-jest version

[patoncrispy]

This resolves an issue where constructor parameters are considered code branches and are not covered by code coverage. istanbuljs/istanbuljs#70

[ahnpnl]

This issue was already fixed in master branch. If you check release 7.0.0-alpha.2 the coverage works. Simply updating to latest ts-jest actually doesn't solve the issue. Because now we switch to AST transformer that's why the coverage works.

thank you for your chore PR :)

[thymikee]

That's still covered by semver range, but oh well 🤷‍♂️

@ahnpnl I'm thinking about publishing stable somewhere soon, but I'd like to wait for Jest 24 to happen (the release is really close), so we don't end up with 2 breaking changes in one month or so.

[ahnpnl]

it's nice to hear that v24 is coming. I agree let's wait for Jest 24 👍

[thymikee]

It has TS support built in (jestjs/jest#7533), backed by Babel. Do you think it makes sense to move away from ts-jest at some point? @babel/preset-typescript not feature complete with TS, but it works pretty well for majority of usecases. cc @wtho

[ahnpnl]

My personal opinion about this is I prefer ts-jest more because I use type checking a lot in test file + const enum + namespace. Other advantages of ts-jest comparing to @babel/preset-typescript can be found in ts-jest documentation as well.

I wonder if somehow we can create a switch for the users either to use ts-jest or use default @babel/preset-typescript. That would be the best. Maybe we need to read the configuration of jest in our preset and decide whether the preset should use ts-jest or @babel/preset-typescript.

[wtho]

I am not aware about all the differences between @babel/preset-typescript and TS, could you link or list them? Would be awesome.

it works pretty well for majority of usecases

If users would quite often require full TS features, e. g. a custom tsconfig.json or rely on type-checking-tests, I would definitely prefer keeping the full feature set through ts-jest. But I guess we cannot find out how often this is actually used by the community. It really depends on how big this majority really is.

I would also be interested in the arguments of why to move away from ts-jest. Of course it would be one big dependency less to manage (and dealing less with semver-issues), but on the other hand the decision should serve the community, especially now it seems like we handled most of the issues that came with the recent ts-jest changes.

I do not want to challenge any opinion, I just want to learn more about the drawbacks here.

[thymikee]

I am not aware about all the differences between @babel/preset-typescript and TS, could you link or list them?

https://babeljs.io/docs/en/babel-plugin-transform-typescript#caveats

It's just a thought, in this preset we abstract most of the config for ts-jest users, so I guess that's not a big deal and we should most likely keep using it

I can imagine Babel being faster than TS in larger projects, but then again it's only on the first run.

[wtho]

My personal experience with jest-preset-angular was that it JustWorked™ and I could adjust it from there. Before I tried to setup jest with angular, but I could not get it to work.

Having a working preset with the ability to adjust any setting in seconds is just awesome.

I would be totally open to move away from ts-jest at some point, given there are changes with ts-jest or @babel/preset-typescript.