Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate "version" and "publish" commands #961

Closed
shawnbot opened this issue Aug 6, 2017 · 17 comments
Closed

Separate "version" and "publish" commands #961

shawnbot opened this issue Aug 6, 2017 · 17 comments
Milestone

Comments

@shawnbot
Copy link
Contributor

@shawnbot shawnbot commented Aug 6, 2017

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
Copy link
Contributor

@danielo515 danielo515 commented Aug 10, 2017

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
Copy link
Member

@evocateur evocateur commented Aug 23, 2017

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

@griest024
Copy link

@griest024 griest024 commented Sep 17, 2017

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
Copy link

@KingScooty KingScooty commented Nov 29, 2017

+1 for --skip-version.

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

@azu
Copy link
Contributor

@azu azu commented Jan 23, 2018

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
Copy link

@joebowbeer joebowbeer commented May 10, 2018

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
Copy link

@morgs32 morgs32 commented May 10, 2018

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
Copy link
Contributor Author

@shawnbot shawnbot commented May 10, 2018

@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
Copy link

@morgs32 morgs32 commented May 10, 2018

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

@shawnbot
Copy link
Contributor Author

@shawnbot shawnbot commented May 10, 2018

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
Copy link

@morgs32 morgs32 commented May 10, 2018

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
Copy link
Contributor Author

@shawnbot shawnbot commented May 10, 2018

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
Copy link
Member

@evocateur evocateur commented May 11, 2018

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...)

@evocateur evocateur added this to the v3.0.0 milestone May 11, 2018
@danielo515
Copy link
Contributor

@danielo515 danielo515 commented May 11, 2018

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
Copy link
Contributor Author

@shawnbot shawnbot commented May 11, 2018

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! ✌️

evocateur added a commit that referenced this issue Jul 27, 2018
BREAKING CHANGE:
* `--preid` now defaults to "alpha" during prereleases:

  The previous default for this option was undefined, which led to an awkward "1.0.1-0" result when passed to `semver.inc()`.

  The new default "alpha" yields a much more useful "1.0.1-alpha.0" result. Any previous prerelease ID will be preserved, just as it was before.

* `--no-verify` is no longer passed to `git commit` by default, but controlled by the new `--commit-hooks` option:

  The previous behavior was too overzealous, and the new option operates exactly like the corresponding [npm version](https://docs.npmjs.com/cli/version#commit-hooks) option of the same name.

  As long as your pre-commit hooks are properly scoped to ignore changes in package.json files, this change should not affect you. If that is not the case, you may pass `--no-commit-hooks` to restore the previous behavior.

Fixes #277
Fixes #936
Fixes #956
Fixes #961
Fixes #1056
Fixes #1118
Fixes #1385
Fixes #1483
Fixes #1494
@shawnbot
Copy link
Contributor Author

@shawnbot shawnbot commented Jul 27, 2018

❤️

nicolo-ribaudo pushed a commit to babel/lerna that referenced this issue Dec 18, 2018
BREAKING CHANGE:
* `--preid` now defaults to "alpha" during prereleases:

  The previous default for this option was undefined, which led to an awkward "1.0.1-0" result when passed to `semver.inc()`.

  The new default "alpha" yields a much more useful "1.0.1-alpha.0" result. Any previous prerelease ID will be preserved, just as it was before.

* `--no-verify` is no longer passed to `git commit` by default, but controlled by the new `--commit-hooks` option:

  The previous behavior was too overzealous, and the new option operates exactly like the corresponding [npm version](https://docs.npmjs.com/cli/version#commit-hooks) option of the same name.

  As long as your pre-commit hooks are properly scoped to ignore changes in package.json files, this change should not affect you. If that is not the case, you may pass `--no-commit-hooks` to restore the previous behavior.

Fixes lerna#277
Fixes lerna#936
Fixes lerna#956
Fixes lerna#961
Fixes lerna#1056
Fixes lerna#1118
Fixes lerna#1385
Fixes lerna#1483
Fixes lerna#1494
@lock
Copy link

@lock lock bot commented Dec 27, 2018

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.

@lock lock bot locked as resolved and limited conversation to collaborators Dec 27, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants