supporting prerelease

[Raynos]

One usage pattern I have for prelease is something like this:

github fork foo/bar
cd bar
git checkout -b fix-shit
/* code code code */
npm version major.minor.patch-fix-shit
git push origin --tags
cd somewhere/else
npm i Raynos/bar#vmajor.minor.patch-fix-shit -S

When working on modules i'm not the owner of I have no right to increase the patch version as the major.minor.patch line is a single linear line maintained by a central author.

However I can change a new pre release with my branch name to say "this is the module at this version + my unreleased changes"

I then wait for my pull request to get merged and update to the next major / minor / patch number. However in the meanwhile i directly install the tag for my unreleased code locally .

[DamonOehlman]

The metadata parts of semver are the bits I really get annoyed about as I think they get abused more than anything, so I don't think slimver will ever support them, though I think what you've outlined above is a good example of where it's useful. That said I think your workflow still works without needing the versioning system to support any additional -metadata as the tooling nicely flicks into a different mode in this case (pulling from github repos instead).

I guess I'm considering it very similar to what you describe about not publishing experimental or unstable stuff to the package manager, but rather sourcing it from a secondary location. So which major.minor.patch-fix-shit is something that definitely happened in the evolution of the software package, from a package manager history perspective it's invisible. Whether it's represented it SCM history or not I'm indifferent about.

[Raynos]

@DamonOehlman

the tooling does not flick into a different mode.

npm makes strong hard assumptions about what version means. if it sees two package.jsons with the same version number but with different git shas you run into a cache invalidation problem, npm refuses to bust the cache even though shas are different.

Every npm artifact you install MUST have a unique version.

[DamonOehlman]

Then IMO that is an error. I think NPM should apply the following logic instead:

• If it has a valid version number then should be from my "known and trusted source" and am free to cache it at will.
• If it is a alternative version syntax (i.e. not semver, slimver, whatever) then I can download it from the alternative source, but caching it is not permitted.

I realise this creates overhead (and potentially issues) when you go on to create derivative tools such as npmd but I think it's a fair approach. If we are about simplifying behaviour, then I think all behaviour needs to be simplified and if the use of an alternative package source comes with some overhead, then that is something that should happen.

In your particular patch case, I see the package manager as obtaining an alternatively sourced version of the same package, Raynos/bar#fix-shit rather than the "official" bar package. The version number in the package.json could be the same for all the package manager cares, I mean you've haven't made any assertions about which package you've required as you've specifically told it to grab stuff from a very specific git endpoint.

I'm absolutely sure you have a point, as I hear the voice of experience talking. Given that, is there no other way to solve this apart from using metadata?

[Raynos]

npm has a bug.

its called its doing a.version === b.version instead of a.md5 === b.md5. It's cache just needs to be fixed.

However it's still nice to express the prelease information.