Framework: Transitive Dependencies Automatically Upgraded

[plaliberte]

I'm submitting a bug report

• Library Version:
  All pre-release versions

Current behavior:

In order to avoid potentially chaotic auto upgrades, I like to pin my dependencies to a specific version (No ^ and no ~ in front of the version). Aurelia is still at the point where we are using pre-release semver all our libraries. Most, if not all, Aurelia libraries specify a caret ^ at the front of the dependency version for their own direct dependencies. This means that all future pre-release versions of that library will match. This results in situations like mine where a developer is trying to explicitly control dependency version numbers without having a simple way to explicitly control the version numbers of transitive dependencies.

If I have a project that had a pinned dependency for the aurelia-framework dating back a couple of months; pulling a copy of that project today and running a new npm install will pull down the latest RC versions of all their transitive dependencies.

Often times, this will not be an issue, but there are a fair amount of cases that will result in problems. The aurelia-pal library is a good example that has seen quite a bit of churn over the past months and has seen some breaking changes. These would get pulled in as a transitive dependency for an older version of aurelia-framework and the breaking changes would result in a broken application where it functioned with the same direct dependencies previously.

---

What is the best way to define my application and the aurelia dependencies that it relies on in order to get a repeatable build process that will be future proofed against changes to transitive dependencies?

[EisenbergEffect]

We are releasing 1.0 next week.

[plaliberte]

@EisenbergEffect will you continue to use the caret for dependencies of packages going forward after the release of 1.0 next week? or is it possible to pin dependencies down or at minimum switch down to patch version changes only with ~

[EisenbergEffect]

@niieani Do you have any opinions on this?

[niieani]

Well I'd say it's the developers responsibility to lock dependencies in their projects to whatever they prefer. If we're going to follow SemVer after 1.0 (meaning: ANY breaking change would bump the version to 2.0.0, then 3.0.0, then 4.0.0, etc.) then I'd say we can leave the caret ^ as it only signifies a minor bump, i.e. ^1.0.0 will only update to 1.x.x, which, according to SemVer, can only contain backwards-compatible features and fixes.
Since our packages our modular, following SemVer will mean the versions won't "sync-up" - i.e. in a year our router might be at 2.0.0, but PAL at 9.0.0.

Personally, I don't see that as a problem - versions are for computers, not for people.
There's also the marketing aspect, of course, but perhaps to signify a marketing "release" version we could then have a codename for each time we want to signify "major developments", like Ubuntu / Debian teams do (and many others).

Since beta releases are non-SemVer, this has been a problem for the OP and possibly others. From 1.0 on, if following SemVer, I think this will become a non-issue.

[doktordirk]

hopefully. non semver beta numbers wasnt a good idea

[plaliberte]

@niieani you say

If we're going to follow SemVer after 1.0 (meaning: ANY breaking change would bump the version to 2.0.0, then 3.0.0, then 4.0.0, etc.) then I'd say we can leave the caret ^ as it only signifies a minor bump, i.e. ^1.0.0 will only update to 1.x.x, which, according to SemVer, can only contain backwards-compatible features and fixes.

Are you planning on following semver after 1.0?

[AshleyGrant]

We've been following semver all along, including with the RC and Beta releases. 1.0.0-rc.1.0.2 follows the semver spec exactly:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

But anyways, I haven't heard anything that would suggest we'll be abandoning semver for the versioning of our libraries. I agree with @niieani that switching to carets is a good idea for the various libraries that make up Aurelia.

[niieani]

@AshleyGrant We've not been following SemVer. While we've been semantically correct in the pre-release identifiers (in that they mimic SemVer), they are all non-SemVer, in the sense they cannot be used programmatically and locked with the caret or tilde the same way as x.x.x.

You can check it out yourself. An example package with breaking changes that broke stuff for users in the past was aurelia-webpack-plugin. Try picking that one and locking to ~1.0.0-beta.1.0.2.
You'll get a match with the breaking releases such as 1.0.0-beta.2.0.0, 1.0.0-beta.3.0.0, and 1.0.0-beta.4.0.0, even though the beta tag indicated 3 major version bumps. Unfortunately there's no way around it unless you'd lock to a single prerelease version - that's how SemVer is designed.

[plaliberte]

@niieani The best way I've found to get npm to respect pre-release major and minor version bumps is to use ranges in your versions.

That way, you could version your dependencies on >=1.0.0-beta.1.0.2 <1.0.0-beta.2.0.0 if you wanted to do roughly the same thing as ~1.0.0-beta.1.0.2.

That does make your package.json a whole lot messier though.

[plaliberte]

@EisenbergEffect @niieani to clarify, after 1.0 release next week, can we strive to always accompany breaking changes to a library only with major version bumps?

[EisenbergEffect]

Yes, absolutely. We don't intend any breaking changes for a while. If they do happen, they will always have a major version change and these things will be announced on the blog. The only exception I can think of is if something accidentally slips through somehow. We certainly don't intend to break things on a minor version. Previously, we did have some issues on the pre-release versioning. That shouldn't happen after 1.0.

[AshleyGrant]

@niieani, you're confusing the semver spec and npm's implementation, which are two different things, unfortunately.

[plaliberte]

Thank you @EisenbergEffect

[niieani]

@AshleyGrant I don't think I am, but I'd love to be corrected if I'm wrong! How would you properly lock our webpack-plugin to v1 major prerelease, say 1.0.2 according to SemVer, not NPM's implementation?

[AshleyGrant]

What I'm saying is that ^ and ~ aren't part of semver. They're something invented by the npm team. The problem is that there isn't really a way to lock it in, from what I've found w/npm.

[niieani]

@AshleyGrant I stand corrected! 😊 In that case I was referring to the NPM's SemVer implementation, which is the only important thing here anyway. :)