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.json
s.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 13
- Comments: 42 (20 by maintainers)
Commits related to this issue
- chore: publish --canary command was running with errors Check https://github.com/lerna/lerna/issues/1769 for more info. — committed to accera-tech/solar-components by menosprezzi 4 years ago
- ci: try --no-push --no-git-tag-version instead of --canary temporarily reference: https://github.com/lerna/lerna/issues/1769#issuecomment-580741246 — committed to mdx-js/mdx by JounQin 4 years ago
- ci: try --no-push --no-git-tag-version instead of --canary temporarily reference: https://github.com/lerna/lerna/issues/1769#issuecomment-580741246 — committed to mdx-js/mdx by JounQin 4 years ago
- merge (#100) * chore(release): publish 1.3.4-alpha.0 * Revert "chore(release): publish 1.3.4-alpha.0" This reverts commit 95cd0720 * chore(release): publish 1.3.4-alpha.1 🙋♀️ * Revert "... — committed to accera-tech/solar-components by eduardodusik 4 years ago
- Develop (#99) * feat(ac-collapse): basic component functionality * merge (#100) * chore(release): publish 1.3.4-alpha.0 * Revert "chore(release): publish 1.3.4-alpha.0" This reverts commi... — committed to accera-tech/solar-components by eduardodusik 4 years ago
- fix(platform-ie): alignment, missing icons and colors fallback (#101) * chore(release): publish 1.3.4-alpha.0 * Revert "chore(release): publish 1.3.4-alpha.0" This reverts commit 95cd0720 * ... — committed to accera-tech/solar-components by menosprezzi 4 years ago
- try actions/checkout@v1 https://github.com/lerna/lerna/issues/1769 — committed to gregjoeval/package-library by gregjoeval 4 years ago
- Switch to actions/checkout@v1, see https://github.com/lerna/lerna/issues/1769 — committed to rjsf-team/react-jsonschema-form by epicfaace 3 years ago
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:I was encountering the same issue with GitHub Actions. I was able to solve it by using the
actions/checkout@v1
action instead ofactions/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 thegit 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.@menosprezzi Great thanks, it works! https://github.com/mdx-js/mdx/runs/419430015?check_suite_focus=true#step:10:468
@JounQin & Guys,
I’m using this command in my Github Actions CD in order to achieve the same behaviour of the
--canary
param: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 ongit
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: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 to0.0.0
and was using this command with lerna 2.11:This successfully published
0.0.1-snapshot.$sha
to the NPM registry. Here’s the relevant output in the prompt:After upgrading to 3.13.1 I updated this command to do the following instead:
Which now attempts to set the version to
null-snapshot.<something>+<sha>
: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:
--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.