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

feat: Split lerna version from of lerna publish #1522

Merged
merged 17 commits into from
Jul 27, 2018

Conversation

evocateur
Copy link
Member

@evocateur evocateur commented Jul 26, 2018

Description

To facilitate further refactoring, the gigantic PublishCommand needs to be split in two. Several flags were deprecated and replaced with clearer options, but remarkably only two technically breaking changes resulted from ~2 weeks of work.

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

Motivation and Context

Fixes #277
Fixes #936
Fixes #956
Fixes #961
Fixes #1056
Fixes #1118
Fixes #1385
Fixes #1483
Fixes #1494

This PR lays the groundwork for #1091 (and #1513) by making lerna publish only directly worrying about publish itself, not all those other complicated versioning decisions.

How Has This Been Tested?

Ported unit tests, with "full-bleed" integration tests of npm publish thanks to the new --dry-run flag in npm@6.

Types of changes

  • New feature (non-breaking change which adds functionality)
  • Breaking change (internal tools)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

 * share composed options more cleanly with publish + changed
 * add version lib mocks to unblock non-canary publish tests
 * handle early return from version command
 * Use inline snapshots for canary tests, adding sequential cases
 * integration/publish: remove --skip-git, --skip-npm, --cd-version flags
 * integration/publish: pass --dry-run via env var
BREAKING CHANGE:
The previous default for `--preid` was undefined, which led to an awkward "1.0.1-0" result.

It will now default to "alpha", which yields a more useful "1.0.1-alpha.0" result.
Any previous prerelease ID will be preserved, just as it was before.
- package-5: 1.0.0 => 1.1.0-alpha.SHA (private)

Successfully published:
- package-1@1.0.1-alpha.0+SHA
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity what's the benefit of -alpha.0+SHA vs -alpha+SHA

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This solves most of #277, allowing ^ ranges of canary prereleases to evaluate correctly. Without the .0 after the prerelease id, semver attempts to parse the git SHA as a number, which leads to very erratic behavior as SHAs are not guaranteed to start with a number, etc.

https://semver.npmjs.com/ is a good playground to demonstrate this. Try it with lerna at range ^3.0.0-beta.10, and you'll notice 3.0.0-beta.9 isn't highlighted:
image

Semver ignores anything after the +, hence stashing the SHA there. It's meant to dedupe the tarball when attempting to upload, since there might be multiple foo-pkg@1.0.1-beta.4 (with different +SHA values) published. (This is why it's a good idea to use --exact with --canary when you're dealing with contentious feature branch publishes)

@evocateur evocateur merged commit 8b97394 into lerna:master Jul 27, 2018
@evocateur evocateur deleted the split-version-from-publish branch July 27, 2018 17:13
@morgs32
Copy link

morgs32 commented Jul 29, 2018

@evocateur I salute you this looks so promising. I am curious about the bit of documentation that strongly discourages running lerna version from a branch. I kind of figured that I'd manually be incrementing versions on a branch and in a PR, and then on merge to master I'd lerna publish from-git. But is that not a wise idea? What sort of process would you suggest or what did you have in mind?

(This part added later) Actually, I think your documentation is sufficient I just had to read it a couple times. Do think doing this in GitHub on my monorepo would remove the concern?
image

@evocateur
Copy link
Member Author

@morgs32 My biggest concern with making tagged releases in feature branches is that the tags get mangled when merging.

I'm not sure if rebase merge would be any safer, since if it was rebasing onto upstream commits, the SHAs would change and thus the annotated tag(s) would be "broken", as the SHA it points to no longer exists. However, I haven't tried rebase merge in a long time, and I don't recall if git rebase itself preserves tags.

One of my goals in the near future is to improve the "auto-publish from CI" experience, perhaps with a subcommand lerna publish release. I envision some configurable branch awareness that would publish untagged prereleases on feature branches (or PRs only?) and then on master (or latest, whatever your "default" branch is configured to be) it would publish with tags, even creating github releases with changelogs (if you're using conventional commits).

So please let me know if lerna publish from-git works after a rebase merge, I would like to figure this out, even if it is "just" a clarification to the documentation!

```json
{
"command": {
"publish": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this correct @evocateur ? Do you configure lerna version by configuring publish on lerna.json ? Seems confusing

@evocateur
Copy link
Member Author

evocateur commented Aug 12, 2018 via email

nicolo-ribaudo pushed a commit to babel/lerna that referenced this pull request 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 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

Successfully merging this pull request may close these issues.

4 participants