--canary results in duplicate package error from npm

[JamesHenry]

This is one of those reports where I feel like I must be doing something wrong, because I cannot find anybody else reporting this issue, and I would have thought almost everyone would run into it if they use --canary. So I apologize if this is obvious, but I'm stuck 😅

Expected Behavior

I have seen it referenced in many comments that --canary is intended to be used as a way to publish a version, either nightly or after every commit.

I would love to be able to use it in CI on every commit.

Current Behavior

I have been trying to experiment with making it work on every commit, but I seem to be running into the fact that npm strips away the +SHA from the version before publishing it, and so if a commit does not cause a version increase (e.g. build file change, chore etc), the npm publish will fail because the version already exists.

E.g.

{
   "name": "foo",
   "version": "0.1.1-alpha.0+9f708c0",

Will be published as 0.1.1-alpha.0. I validated this directly by running npm publish after I had the issue via lerna, npm always removes the "build metadata".

...
Error: 403 Forbidden - PUT https://registry.npmjs.org/foo - You cannot publish over the previously published versions: 0.1.1-alpha.0

Steps to Reproduce (for bugs)

1. lerna publish --canary
2. git commit -m "chore: something which doesn't change the version"
3. lerna publish --canary

Context

Your Environment

Executable	Version
lerna --version	3.10.5
npm --version	6.4.1 (also tried on others)
node --version	8.12.0 (also tried on others)

OS	Version
macOS	10.14

[JamesHenry]

Is the idea that you anticipate that the publish build job will fail in these cases and handle it accordingly? If that's the case I'm still surprised I have not seen other people referencing it

[JamesHenry]

Ok ignore me, I can no longer reproduce - the number after alpha now seems to be reliably incrementing, so the SHA is not the only point of differentiation.

Thanks for your work on lerna!

[evocateur]

If I had to guess, it was perhaps due to missing git history in the CI build ("shallow" clone)? --canary uses git describe under the covers to get the "number of revisions since last release tag", which it then uses for that incrementing prerelease number. The SHA isn't useful as a semver prerelease since it can't be used as a number when comparing against another version, and thus is stuck behind the + just to make the exact revision more easily traceable by humans.

[mocheng]

@JamesHenry I have same issue as this issue depicts #1893 .