lerna: Canary publish results in null-alpha.200+925ed27

I am trying to publish a canary for not-yet-released package.

When I run

$ npx lerna publish --canary --force-publish

I get following:

Found 3 packages to publish:
 - @xxx/aaa => null-alpha.200+925ed27
 - @xxx/bbb => null-alpha.200+925ed27
 - @xxx/ccc => null-alpha.200+925ed27

My lerna.json has version:

{
  "lerna": "3.4.3",
  "packages": [
    "aaa",
    "bbb",
    "ccc"
  ],
  "version": "4.0.0"
}

My root package.json has same version 4.0.0 as well as all other package.jsons.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 13
  • Comments: 42 (20 by maintainers)

Commits related to this issue

Most upvoted comments

Well, just imagine the case when developer wants to release something as nightly builds but lerna kinda forces the dev to have at least 0.0.1, which (in my opinion) should not be necessary for the given case.

It would be nice if the documentation at least warns about this, because now it was giving me headaches.

Final comment, which I think would definitely categorize this as a bug and a regression in --canary builds.

I tried doing a publish without --canary and the versions were correct:

yarn lerna publish --registry <registry> --no-git-tag-version --no-push --force-publish='*' --dist-tag latest --preid snapshot prepatch
yarn run v1.15.2
lerna notice cli v3.13.1
lerna info current version 0.0.0
lerna notice FYI git repository validation has been skipped, please ensure your version bumps are correct
lerna WARN force-publish all packages
lerna info Assuming all packages changed
lerna WARN version Skipping working tree validation, proceed at your own risk

Changes:
 - @scope/private-package: 0.0.0 => 0.0.1-snapshot.0 (private)
 - @scope/package-1: 0.0.0 => 0.0.1-snapshot.0
 - @scope/package-2: 0.0.0 => 0.0.1-snapshot.0

I was encountering the same issue with GitHub Actions. I was able to solve it by using the actions/checkout@v1 action instead of actions/checkout@v2 (version 2). Maybe this helps some of you folks.

I would assume that from lerna side it would be a valid improvement to just read the lerna.json version in case of fixed versions.

Update: ok i see the underlying issue. with an independent versioning scheme, the lerna publish logic does not rely on git describe. whereas, with a fixed versioning scheme, it does. this means that, if your repo does not have an annotated tag that matches “v*..” for the branch you wish to publish, one that the git describe algorithm can find, … then lerna publish fails with the “null” version bug.

our use case: our master branch version has no annotated tags, because we haven’t yet published anything. i.e. master is truly the canary; we use version branches to track semvers. we want to prepublish a canary for our (not yet published) master, and this breaks lerna when run in a non-independent/fixed versioning scheme.

our hacky fix: push an annotated tag (it must be an annotated tag, not a lightweight tag) that satisfies lerna’s tag-match criterion.

i’m not a lerna dev, only a user. this part of lerna seems fairly buggy, unfortunately.

the null comes from lerna’s attempt to infer the most recent “vx.y.z” tag for your current branch. it uses a git command (git describe) for this, and it is this git command that finds no matching tag. there is a bug in lerna publish, where it does not handle this situation gracefully.

this issues does not occur with independent versioning, as lerna’s algorithm for inferring the versions there is different, and quite a bit more reliable. it is only with uniform versioning where the git describe algorithm gets involved, and to … not such great effect.

as to why the situation occurs? it is frankly a bit of a mystery to me. there seems to be issues with publishing new versions in version branches, where lerna’s heuristics fail: a subsequent lerna publish from master, after a semver publish in a verison branch… usually results in nulls, and i quite honestly have no idea how to resolve this reliably. but it means that every time i publish on a version branch… master builds fail with nulls, and i have to scramble to figure out how to resolve this… each and every time.

in my opinion, when i’m doing a --canary prepatch publish in master (master is never doing semver releases, anyway)… git should not be consulted at all. the version in lerna.json should suffice to form the basis for the versions of the packages to be published.

@JounQin & Guys,

I’m using this command in my Github Actions CD in order to achieve the same behaviour of the --canary param:

lerna publish prerelease -y --force-publish=* --no-push --no-git-tag-version --dist-tag alpha

Since the --canary dont push any git tags, the --no-push and --no-git-tag-version accomplish that. And the --dist-tag alpha will mark this version as an alpha release on NPM.

Hope it helps!

--canary has always depended on git to determine what changed and how to version it. If your Docker thingy has no use for git, I would take your explicit version and skip --canary altogether:

# --no-git-tag-version "turns off" all git operations for `lerna version`
npx lerna version ${MY_EXPLICIT_VERSION} --no-git-tag-version --exact --force-publish --yes

# "from-package" is the only bump argument for `lerna publish` that does not require git
npx lerna publish from-package --yes

It’s a “global” release, but then I’m not sure how you’d expect to pick and choose without git around to tell you what’s changed.

My situation is similar to the above, I have not made a release yet at all of my package. There are no tags, no semver releases on the NPM registry. I am trying to publish a canary build. I have package.json version set to 0.0.0 and was using this command with lerna 2.11:

yarn lerna publish --cd-version=patch --canary=snapshot --skip-git --npm-tag latest --exact

This successfully published 0.0.1-snapshot.$sha to the NPM registry. Here’s the relevant output in the prompt:

lerna info version 2.11.0
lerna info canary enabled
lerna info current version 0.0.0
lerna info Checking for updated packages...
lerna info Comparing with initial commit.
lerna info Checking for prereleased packages...

Changes:
 - @scope/private-package: 0.0.0 => 0.0.1-snapshot.723ade45 (private)
 - @scope/package-1: 0.0.0 => 0.0.1-snapshot.723ade45
 - @scope/package-2: 0.0.0 => 0.0.1-snapshot.723ade45

After upgrading to 3.13.1 I updated this command to do the following instead:

yarn lerna publish --registry <private-registry-url> --canary --no-git-tag-version --no-push --force-publish='*' --dist-tag latest --preid snapshot patch

Which now attempts to set the version to null-snapshot.<something>+<sha>:

lerna notice cli v3.13.1
lerna info canary enabled
lerna WARN force-publish all packages
lerna info Assuming all packages changed

Found 2 packages to publish:
 - @scope/package-1 => null-snapshot.2625+04378626
 - @scope/package-2 => null-snapshot.2625+04378626

Lerna 2.x allowed me to release canary patches without having any tags in the repository, and thus without having done a single release before. Does Lerna 3.x not allow this?

facing the same issue 😦

any updates ? i can still reproduce this issue with lerna 3.5 … it seems that it expects the first publication to not be “canary”, because it only fails if there are no prior tags. once a first “latest” version has been published, publishing to canary is no problem.

As long as there are reachable v3.x.x tags:

npx lerna publish premajor --canary

--canary no longer accepts an argument in lerna v3. Canary never tags or pushes git changes.

Is your CI clone shallow, by any chance? If so, it’s likely not deep enough to encompass the v4.0.0 annotated tag.

My CI script works well on lerna 2.x but failed on the latest release 3.4.3.

lerna publish --canary=xyz.123 --yes --no-git-tag-version --no-push

similar null prefix is reported. --yes failed to disable prompt which works well in lerna 2.x.