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.

Sign up for GitHub

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

Jump to bottom

Lerna Publish pre-patch/minor/major behavior #936

Closed
mike-robertson opened this issue Jul 24, 2017 · 2 comments
Closed

Lerna Publish pre-patch/minor/major behavior #936

mike-robertson opened this issue Jul 24, 2017 · 2 comments

Comments

@mike-robertson
Copy link

First I just want to say this is a great project! Thanks for putting it out there for folks to use!

Here's my question:
I don't know if there is a way to do this (not documented or I'm stupid) or if there isn't a way to do this, but if I publish a pre-patch/minor/major version, I would like a way for lerna publish to be able to figure out those packages still need a non-'pre' publish on subsequent lerna publish's.

Example:
I have a feature branch which has several packages being updated. I want to be able to deploy that branch to an environment and test against it before merging it into my master branch. Therefore, I need to (I think) do a lerna publish which will get all those affected components since my build process relies on pulling in the actual npm packages. However, I obviously don't want to do a full version bump since this feature is still in testing. So I use the pre-X publish option. This works great!

Then I decide to merge that branch into master after some testing is done. However, now when I run lerna publish, it fails to publish anything because in lerna's eyes, nothing has changed. I would still like to do an actual publish though on those packages that have a pre-X version number. Of course I can go through figure out which things changed and publish those packages manually, but in a project with a lot of packages, that can be pretty tedious.

Questions:

  1. Is there a way to do this currently?
  2. If there is, can that be documented in the readme (or if I just missed it, laugh at me and point me towards it)?
  3. If there is not a way to do that, is it on a roadmap as a feature, or would you entertain putting that as a possible feature? I think it would be very useful for this kind of workflow.

Thanks again for the great project!
@shawnbot shawnbot mentioned this issue Aug 6, 2017
Merged
9 tasks
@evocateur
Copy link
Member

I think you need to do a --canary release in the feature branch, so it avoids adding tags and thereby doesn't break the awareness of "changes since the last (non-canary) release" publish decisions. #960 should help, here.

evocateur pushed a commit that referenced this issue Aug 23, 2017
@shawnbot @evocateur
Improve support for semver prerelease identifiers when publishing (#960)
681c60b 
- Added `--preid` flag to support a custom [prerelease identifier](http://semver.org/#spec-item-9) for non-canary publishes.
- Updated `--cd-version` to support more semver increment keywords.
- Updated `--canary` to allow `--cd-version` customized semver bump (formerly hard-coded to `"minor"`).

Fixes #915, #936
@evocateur evocateur mentioned this issue Jul 26, 2018
Merged
8 tasks
evocateur added a commit that referenced this issue Jul 27, 2018
@evocateur
feat: Split lerna version from of lerna publish (#1522)
8b97394 
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
This was referenced Aug 10, 2018
Closed
Closed
Closed
Merged
nicolo-ribaudo pushed a commit to babel/lerna that referenced this issue Dec 18, 2018
@evocateur
feat: Split lerna version from of lerna publish (lerna#1522)
79dd10f 
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 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.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@evocateur @mike-robertson