Ts-jest: no SemVer warning

[zewa666]

Issue

Since this package does not follow SemVer, build systems, running unit tests automatically, break hard without ever understanding what happened. I'm pretty sure tons of users out there lost some valuable hours today fixing the issue just because SemVer isn't followed and there are no mechanisms in place to warn users about potential breaking changes, or like happened today A FULL REWRITE

Expected behavior

Since it seems the repo owners have their reasons for ditching SemVer, which in all honesty should be revisited to prevent disasters since pretty much the whole NPM community agreed upon that standard, I'd like to see at least any indicator upon installing a new version that breaking changes might result.

Example solution

• Add a postinstall task
• Require the version, check for the new one introducing breaking changes and console.error a help

const package = require('./package.json')

if (package.version === "MY NEW VERSION INTRODUCING A BREAKING CHANGE AND NOT BEING SEMVER COMPATIBLE") {
  console.error('Hey there ... we created a breaking change ... might wanna read more here ...[link]');
}

[huafu]

Hi @zewa666, I understand your situation, but the non following semver is explained in readme, as well as a warning on top about latest version.

I'll look into the post-install thing too, seems a good idea.

BTW, you have now a slack channel to get some help, and a better doc (both linked in readme as well).

[zewa666]

Well I did read in the readme what you're doing, just not why. I'm not gonna argue here about what your guys motivation to do so was, most likely I ain't gonna like/agree the arguments anyway. What I'm after here is that these type of things do cost actual time and money. The fix is easy, but figuring out why that happened involved reading through CI logs, running things locally just to see that something typically taken for granted, does not any more apply.

So having at least the install warning would save people precious time figuring out the issue. More over since this breaking change also killed important use cases like the ability to do import * as foo from "foo", which's switch would result in tons of rewrites, remodelled custom typings for ancient js dependencies etc.

[huafu]

For the import *, will try to get the fix deployed asap (it's in #736).

Anyway, you lose money, but this is OSS, so you did not lose the money coding this tool, as well as contributors didn't get paid writing it, would be nice to stay calm here ;-)

[zewa666]

@huafu sorry for the tone, you're right about your statement, it's just the reaction you have after wasting time that could have been spent for something more productive.

Anyways thanks for the quick reacting

[yavin5]

Please begin using semantic versioning.

[huafu]

@yavin5 https://kulshekhar.github.io/ts-jest/#versioning

[yavin5]

@huafu My point is: people come to this issue page because of a problem, and the cause is: you are not following semantic versioning. I'm asking you to please begin following semantic versioning. If Jest themselves are not, we should ask them to as well.

[huafu]

@yavin5 sorry I thought it was explained why ts-jest does not follow semantic versioning.

/cc @kulshekhar

[GeeWee]

Jest is, but we want to release ts-jest in lockstep with jest, so you know that a Jest version 23 uses a ts-jest version 23.

I think a postinstall script would be an excellent idea, and I'm all for accepting a PR with those changes. Seems like work is going on in #739 about that.

While we do try to limit our breaking changes to when Jest updates major versions, this isn't always possible. E.g. we've been doing a large rewrite, and it's either pushing that out now with the breakage that will occur, or not doing any maintenance until Jest release a major version.

However, do keep in mind that this is an OSS project, with unpaid volunteers. We're saving you a lot of time not having to maintain the infrastructure for your tests yourselves. I understand you might be frustrated, but the tone in this thread is only conductive to one thing - pushing maintainers away.

Please think about this in the future.

[kulshekhar]

@yavin5 we don't have the resources to follow semantic versioning and implement it correctly.

If you, the company you work for or someone else is willing to offer their time/expertise to manage this on a permanent basis, it'll be welcome. Short of that, this won't be a productive discussion at all.

[GeeWee]

(I'm going to reopen this as we actually have a PR tracking it though, please be civil)

[zewa666]

Jest is, but we want to release ts-jest in lockstep with jest, so you know that a Jest version 23 uses a ts-jest version 23.

So is this the only reason @GeeWee ? I'm trying to understand why that would be important. Personally I wouldn't care what version ts-jest is on. It sounds pretty similar to saying Redux should follow Reacts versioning because they are used together. Ok granted Redux may be used with something else but I hope you get the point. If ts-jest would define a peerDependency to jest all of that wouldn't really matter.

If the current version of J is 23 and TJ is 250 just add a peer dependency to J 23.x.x
If tomorrow a new version for J of 24 is released, do a new major release for TJ 251 with an update peer dependency to 24 and all would be fine. As long as you lock to minors all should be good.

I think the whole trouble with the discussion is because people do not fully understand your motivation for breaking SemVer and/or the arguments to do so are not clear enough or maybe even invalid. So maybe you guys could try to explain your motivation in a bit more detail.

---

Also @kulshekhar please don't use killer phrases like "But this is OSS, we're doing it for free so take it or leave it". They don't really add any value. Most of us do contribute to OSS with various amounts of time and we all understand the situation. Yet this is no professional argument to counter a question. Closing a topic because it's uncomfortable neither is.

I just want to add that your guys work is respected. Not only respected but it works really great and for me ts-jest was the sole reason to move my whole testing stack from Karma/Jasmine to Jest.

[kulshekhar]

please don't use killer phrases like "But this is OSS, we're doing it for free so take it or leave it". They don't really add any value

I didn't say that but I probably should have. At least until I stop seeing comments like this:

I'm not gonna argue here about what your guys motivation to do so was, most likely I ain't gonna like/agree the arguments anyway. What I'm after here is that these type of things do cost actual time and money.

Closing a topic because it's uncomfortable neither is.

I closed it because I didn't see anyone offering to help implement this and we're not in a position to implement this.

[GeeWee]

So is this the only reason @GeeWee ? I'm trying to understand why that would be important. Personally I wouldn't care what version ts-jest is on. It sounds pretty similar to saying Redux should follow Reacts versioning because they are used together. Ok granted Redux may be used with something else but I hope you get the point. If ts-jest would define a peerDependency to jest all of that wouldn't really matter.

I'll be honest that this decision was before my time, but yes.
I see you with the react/redux example. I think a better example is react-redux and React.
I see this package does declare peerdependencies (but it also supports pretty much every version of React, we don't really have that luxury)

If the current version of J is 23 and TJ is 250 just add a peer dependency to J 23.x.x
If tomorrow a new version for J of 24 is released, do a new major release for TJ 251 with an update peer dependency to 24 and all would be fine. As long as you lock to minors all should be good.

The only issue I see here is if I'm on version 22 of Jest. There's no real easy way to tell what peerDependencies a package specifies, so I'd have to go through all of the versions until I stopped getting a peerDependency error.
I recognize this is a tradeoff however, and while I'm personally open to switching the versioning scheme, depending on the arguments for either side.
(We do try to group breaking changes and release them when Jest upgrades, but as mentioned earlier in this specific case it wasn't possible)

Perhaps @kulshekhar knows more about the original reasoning.

[zewa666]

@GeeWee good catch with your example. But there's tooling for this provided by npm itself.

// example for react-redux
npm show react-redux@latest peerDependencies

// Prints
{ react: '^0.14.0 || ^15.0.0-0 || ^16.0.0-0',
  redux: '^2.0.0 || ^3.0.0 || ^4.0.0-0' }

React-redux is definitely a better comparison true.

[kulshekhar]

Perhaps @kulshekhar knows more about the original reasoning.

I didn't use semantic versioning because I didn't have time to review every PR with that in mind. I was never in a position to implement it correctly. I'd rather the library be upfront about it than make promises it can't keep. For every one library that you tell me uses semantic versioning, I can show more that don't use it correctly.

ts-jest is not a library that receives a lot of feature updates. So it seemed like a reasonable decision to follow the jest major version. It keeps things simple.

I'd also like to highlight that throughout the time ts-jest has existed, this is the first time versioning has been an issue. This was because it was an entire rewrite. I didn't plan for the rewrite. It came around because someone (thanks @huafu!) took it upon themselves to improve the library. After that was done, it became a question of waiting for the next major jest release or releasing a breaking change. We discussed and because we didn't know when the next major jest release was going to come out, it was decided to publish this.

Based on the fact that this hasn't been an issue except this one time, I'd take the same decision if I have to do it all over again.

[blieque]

I'm confused. Does only the major version sit in line with Jest? How has ts-jest jumped from 23.1.4 to 23.10.0, and Jest is still only at 23.6.0? I'm getting test errors with these two packages as though moduleNameMapper isn't getting read properly. I can understand the value of tying versions together, but shouldn't the latest 23.x ts-jest work with the latest 23.x Jest? If the changes were a re-write, was there much value in pushing this version before the nest Jest release? I feel like people have spent more time in this thread than they would have saved by running

Not trying to be mean, I'm just wondering. If it's a one-off, it's not much of a problem. :smile:

[GeeWee]

Yes only our major version follows Jest, and we'll often lag behind due to being a little less manned than Jest. Feel free to open a new issue for your particular problem though.

[GeeWee]

Closing this, doesn't seem like anyone's willing to step up and grab the ball.