Skip to content

Instantly share code, notes, and snippets.

@isaacs
Last active August 29, 2015 14:06
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save isaacs/64da1f4fcf8a1e21c347 to your computer and use it in GitHub Desktop.
Save isaacs/64da1f4fcf8a1e21c347 to your computer and use it in GitHub Desktop.

First of all, great post. I agree with almost everything here, both from a technical and political point of view.

It would be a good idea to update the Comparator expansions once SemVer v4 lands. The discussion is happening at npm/node-semver#99. Since it mostly is about changes that were introduced in v3, and you're discussing v2 behavior here, it's not super relevant. But it might be worth talking about how -prerelease tags are handled in ranges. I dunno. Maybe too deep or technical for the intended audience ;)

Please do not take the following nitpick as anything more than an attempt at clarification.

Not long after its introduction, the caret became the default semver save prefix in npm

The caret operator was introduced in semver@2.1.0, on 2013-08-01T23:52:31.371Z. npm's semver version was updated to 2.1 in f36964 on 2013-08-02T20:31:17.000Z, and the first release supporting the caret operator was 1.3.7, on 2013-08-02T20:31:35.000Z.

npm 1.3.7 was included in the Node release of 0.10.16, on 2013-08-16T15:31:10.000Z. This is roughly the time when most people would have actually been able to use the caret operator in the version of npm that they had by default.

The caret was made the default in commit 0a3151c. The first npm release with that default was npm@1.4.3, on 2014-02-17T04:38:36.230Z.

npm 1.4.3 was shipped with Node@0.10.26, on 2014-02-18T22:55:58.000Z. This is when most people would have started seeing ^ used as a default.

So, between the introduction of support of the caret operator to most users until its becoming the default, assuming that everyone is using the latest and greatest stable release of Node, there was a little more 16 Msecs, or just over 6 months.

I don't agree that 6 months is "not long after". That's a considerable portion of the entire time Node and npm have existed!

The real question is why Node v0.8 has continued to ship a known-broken version of npm, when there is a fixed version available. It does not stop at the caret operator. npm v1.2 has a host of known bugs that have been fixed in later releases.

What's worse, the MSI installer leaves Windows users in a position where they cannot reasonably upgrade their version of npm, without manually editing their system Path environ, moving files around on the command line, etc.

The failure update the npm version in Node's standard distribution has marginalized a significant portion of the Node user community, effectively cutting them off from full inclusion in the Node experience.

@dshaw
Copy link

dshaw commented Sep 10, 2014

@isaacs Thanks for the thoughtful feedback. I totally agree that -prerelease tags is an important issue to explore more fully. While usage of -prerelease tags has been fairly limited in module space, it is very relevant for large-scale application development leveraging best practices around npm.

@rvagg
Copy link

rvagg commented Sep 10, 2014

We'll get some edits in to cover your concerns about timing, probably my fault for removing some of the specific dates from the original copy.

-prerelease has been ignored in both articles so far simply because it's way too much detail, already the articles are quite long!

Given the changing semantics in node-semver@4 I believe that there's much more potential for the usefulness of -prerelease and I'd like us to follow-up with a dedicated post about that, probably after npm@2 finally lands.

@rvagg
Copy link

rvagg commented Sep 17, 2014

note now included on the post about the timing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment