Separate "version" and "publish" commands

[shawnbot]

Lerna needs a separate version command.

Why

Folks who use npm a lot are probably comfortable with the separation between the npm version and npm publish commands. For me, this separation is important because it allows me to double- and triple-check things before publishing. When versioning and publishing a monorepo with dozens of packages, the "publish anxiety" factor is even higher. I've worked through some of that anxiety with various permutations of --skip-git and --skip-npm then git diff, but at some point you have to git reset and just trust that Lerna is going to do the right thing.

The other problem is that Lerna doesn't make it easy (possible?) to just publish all of the packages using the existing package.json versions. AFAICT, it's not possible to skip the increment step, which means that you have to run something like this instead:

lerna exec --bail=false npm publish

...which will output a lot of scary npm publish error messages for any of your packages that haven't been bumped since the last release.

We recently introduced a CI-driven automated publishing workflow in Primer, and to get around this we resorted to running a try-publish script, which would only run npm publish if the version in each module's package.json hadn't already been published. Other teams that want to automate publishing will inevitably run into the same issue, and it would stink if they all ended up having to come up with their own solutions for it.

How

There are a couple of ways to go about this:

1. To maintain backwards compatibility with the current CLI API, the publish command could introduce two new options:

   • one that does everything but the git and npm steps, e.g. lerna publish --skip-publish
   • one that only publishes without touching any package.json files, e.g. lerna publish --skip-version

2. If you're comfortable breaking the publish CLI for 2.x users, you could avoid adding any additional options to publish and just move all of the versioning logic over to a new version command.

[danielo515]

This is also a problem for our company.
There many many times where lerna fails on git operations, or npm operations, and I just want to publish the packages, which is not possible. I would add to the request an option for just publish the packages or to just tag the versions without any version bump.

Regards

[evocateur]

I am certainly sympathetic to this request, though I'm not ready to do a breaking change for it...

[griest024]

It would certainly be nice for the CLI to follow npm as closely as possible, but I would settle for non-breaking changes that implement this.

It seems that @shawnbot's proposed --skip-publish switch can be accomplished with --skip-npm --skip-git so all this really needs is a --skip-version switch.

[KingScooty]

+1 for --skip-version.

I've just stumbled across this issue while setting up my CI pipeline to handle publishing.

[azu]

I think #1056 is similar to this issue.

Rough summary:

Task	npm	lerna	Disable / Issue
Versioning	npm version	lerna publish	--skip-git / #961
Publishing	npm publish	lerna publish	--skip-npm / #1056
ChangeLog	--	lerna publish --conventional-commits	Not use --conventional-commits

I think that npm user can get flexibility by running each Task in a sequential order.

• Run script before "Versioning"
• Versioning
• Run script after "Versioning"
• Run script before "Publishing"
• Publishing
• Run script after "Publishing"

By contrast, Lerna can not run each Task in a sequential order.

Versioning -> Publishing -> ChangeLog

#956 point out it.

[joebowbeer]

My CI also needs this change.

Given the usual sequence of operations to publish an npm package:

$ npm version patch
$ git push --tags origin master
$ npm publish

I want lerna to permit a separation of the first two actions from the last.

Related to #653 and #1385

[morgs32]

I'd like to better understand this issue. @shawnbot you say...

Other teams that want to automate publishing will inevitably run into the same issue

What is the issue exactly? That their process is to publish some packages outside the CI pipeline and some in it? That they get errors in a try-publish script because they want that sort of functionality?

I must have started watching this issue a while back because I THOUGHT I wanted something similar but came to be perfectly happy with the current API.

[shawnbot]

@morgs32 We've certainly found a workaround, but I predict that many Lerna users will eventually run into a wall with lerna publish.

Stepping back, I think the underlying problem is really just the inability to inspect the state of your packages (in git or otherwise) before you hit the metaphorical "publish" button. When I run npm version patch, I can check to make sure that package.json was updated to the version I expected and that the corresponding git tag was created. I can't do that with Lerna, and with dozens of packages to manage, that heightens my "publish anxiety". ☹️

[morgs32]

Hmm. To me, lerna publish --skip-npm is the equivalent? Packages get incremented. Git tags created. What am I missing?

[shawnbot]

How do you publish after that? IIRC, if you run lerna publish again it'll bail because there aren't any changes to trigger version bumps. So you need to run lerna exec npm publish, but that will bail if it hits a package that hasn't changed since the last publish.

IMO, it's confusing that there are many Lerna subcommands with presumably equivalent npm commands (init, link, ls, publish, and run) but no version command, and a publish that behaves so very differently.

[morgs32]

I agree on both counts.
As for wanting to run lerna publish again after the --skip-npm, I don't think you should have to. I figured if you were wanting to see the version bumps and git tags you were doing that locally. In which case git reset --hard HEAD~?
If you're in a CI pipeline what's the use for --skip-npm?

[shawnbot]

I guess lerna publish --skip-npm feels like a hack in that case. At least in our case (Primer), it would be a lot more straightforward to be able to:

1. Run lerna version manually, e.g. on a release branch, and inspect the resulting version bumps, update the changelog, etc.
2. Have CI checks that ensure versions are incremented, cross-dependency versions match, etc.
3. Run lerna publish on CI when the release branch merges to master.

Instead, we a hodgepodge of scripts to simulate that workflow: a bump npm run-script that runs lerna publish --skip-nm, a release script that runs lerna exec -- try-publish, and a try-publish script that only calls npm publish if the version of each package isn't already published.

And sure, it works, but it's an awful lot of boilerplate for us to have to maintain.

[evocateur]

I agree that the two should be split. I got started on it a couple weeks ago, but then I stalled (pesky day job/infant son): master...evocateur:split-version-from-publish

Historically, I'm fairly certain lerna publish conflates npm version and npm publish because that's exactly what yarn publish does, and lerna publish was created by the creator of yarn. (Again, I disagree with that design decision, it's just ...a big piece of code...)

[danielo515]

and a try-publish script that only calls npm publish if the version of each package isn't already published.

Thanks @shawnbot for that piece of gods bless. One of the main problems at our company is publish conflicts. I wish Lerna can handle those, but meanwhile your scripts seems like a good workaround.

[shawnbot]

Whoa @evocateur, congrats! I've got a 7mo and a 3yo... it's a lot.

Anyway, I and my GitHub peeps are more than happy to help out if we can; just give a shout! ✌️

[shawnbot]

✨ ❤️

[lock]

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.