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)