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

lerna to publish packages with their current version #1056

Closed
RinatMullayanov opened this issue Oct 6, 2017 · 15 comments
Closed

lerna to publish packages with their current version #1056

RinatMullayanov opened this issue Oct 6, 2017 · 15 comments

Comments

@RinatMullayanov
Copy link

@RinatMullayanov RinatMullayanov commented Oct 6, 2017

How do I tell lerna to publish packages with their current version?
Now lerna is always trying to increase the version of packages ...

I need this because I want to divide the publication process into 2 stages:

  1. First I want to manually raise the package version only in git in dialog mode:
    lerna publish --skip-npm
  2. Only then with the help of CI I want to publish in npm:
    lerna publish --skip-git

I do not need to raise the version twice.

My Environment

Executable Version
lerna --version 2.2.0
npm --version 5.4.2
node --version v6.11.2
OS Version
Windows 10 Pro 1703
@yairkukielka
Copy link

@yairkukielka yairkukielka commented Oct 10, 2017

I want lerna to use the package.json version number to publish without having to bump it since it was already bumped manually by the developer.

In my case, CI doesn't know if it's a breaking change or not, so I expect the developer to do this. So I would use the --yes flag but wouldn't wan't the prompt to ask me what version I want to release. When the branch is merged to master, that's when I expect lerna to just use the version in package.json to publish without new commits.

Something like this would be a nice feature:
package.json:
{ "name": "mypackage", "version": "0.0.2", }

This command:
lerna publish --repo-version-exact
would publish version 0.0.2 without bumping the version

@evocateur
Copy link
Member

@evocateur evocateur commented Nov 15, 2017

If your CI has ways of indicating when a tag has been created, lerna exec -- npm publish (after bootstrap) would accomplish this. Instead of making lerna publish more complicated, I'd rather focus on making --conventional-commits more useful/robust for the automated publishing in CI use-case.

@KingScooty
Copy link

@KingScooty KingScooty commented Nov 29, 2017

lerna exec -- npm publish wouldn't work when one or more of the packages are private. lerna publish respects private packages, however npm publish does not and results in an exit 1 error. I have a few "workspaces" that are bootstrapped by Lerna (local symlinked dependencies), but aren't intended to be published to npm.

Ideally, CI would run a lerna publish with some args that would just push to an npm registry without altering version numbers or affecting change logs.

I've scoured the issues section of Lerna, but have really struggled to find a proper answer for cleanly setting up Lerna with a monorepo in CI.

Because Lerna insists on bumping the package.json regardless of what args are passed, it results in a messy CI integration. If you push changes back to git (package.json, changelogs etc), it then triggers a subsequent build.

Ideally Lerna would have a --ci mode or something that just disabled altering any files within the git repo. So it would just push to npm, and push tags back to git?

Anything more triggers further unnecessary builds. The developer can run the changelog part of lerna lerna publish --skip-npm --skip-git --conventional-commits before pushing to github.

Thoughts?

@azu
Copy link
Contributor

@azu azu commented Jan 24, 2018

lerna exec -- npm publish wouldn't work when one or more of the packages are private. lerna publish respects private packages

I've created can-npm-publish CLI.
It will help lerna exec npm publish pattern.

lerna exec --bail=false can-npm-publish && npm publish

@unregistered
Copy link

@unregistered unregistered commented Mar 9, 2018

@evocateur Is there interest in a PR for this? Conventional commits seems kind of awkward when using lerna in Independent mode.

@evocateur
Copy link
Member

@evocateur evocateur commented Mar 9, 2018

@unregistered I was thinking of implementing a from-git value of the --cd-version option, similar to npm version's positional value of the same name. It would throw if the current commit wasn't tagged, of course. Pull out the paths to publish from git show HEAD --name-only --pretty=format:%D -- packages/*/package.json (adding appropriate package location globs as necessary), and jumping straight to the publish loop.

lerna publish --cd-version from-git

btw, --no-private was added in v3.0.0-beta.1, so now lerna exec -- npm publish could skip packages with "private": true set in their package.json.

@unregistered
Copy link

@unregistered unregistered commented Mar 9, 2018

@evocateur can you clarify what the tag should be for an independently versioned repo? Wouldn't it have to contain the name of the package that's being published?

I think that feature you mentioned might work, just trying to wrap my head around it.

To clarify we publish on every commit we squash to master, but when a commit changes only one package it's wasteful to publish the other 80 packages (and dishonest too, since the patch-level gets bumped but there are no changes).

Edit: I played around with yarn lerna publish --skip-npm --conventional-commits and it works the way I want. It tags packages like @org/package-name@1.0.0, and when it creates git tags, it only updates versions of packages that change. So that's pretty neat.

@evocateur
Copy link
Member

@evocateur evocateur commented Mar 9, 2018

You would also need to pass --yes to the command in CI, of course, otherwise it would break due to hanging prompt. Here's some sketches of output and expected response:

# independent mode with valid tags
$ git show HEAD --name-only --pretty=format:%D -- packages/*/package.json
tag: @scope/package-1@2.9.1, tag: package-2@1.1.0
packages/package-1/package.json
packages/package-2/package.json

In independent mode, the tags themselves are valid arguments to npm-package-arg, and we can map the names back to our internal Package objects. Pretty straightforward.

# fixed mode with valid tag
$ git show HEAD --name-only --pretty=format:%D -- packages/*/package.json
tag: v1.8.0
packages/package-1/package.json
packages/package-2/package.json

Fixed mode is a bit more wrinkly, requiring reverse lookups by pkg.manifestLocation of the list of modified package.json files. Not too terribly difficult, really (except maybe windows because windows sucks).

# no tags found, return no-op with appropriate logging
$ git show HEAD --name-only --pretty=format:%D -- packages/*/package.json
# empty string

I figure throwing is not what we want, it should just behave the same as the "no changes found" case, which is just to exit.

@evocateur
Copy link
Member

@evocateur evocateur commented Mar 9, 2018

To be clear, this would also pretty much require #961, using lerna version instead of the wonky-looking lerna publish --skip-npm.

If it's desired to be completely automated, you'll need to use --conventional-commits. What exactly is "awkward" about that option in a CI context? The changelog generation?

@unregistered
Copy link

@unregistered unregistered commented Mar 10, 2018

@evocateur It's a bit of a pain to get the auto-generated commit and tags sent back to the master branch, since we have branch protection on, commits only enter master through PRs. Not sure what the recommended pattern for that is, I may just be doing something unusual.

@evocateur
Copy link
Member

@evocateur evocateur commented Mar 10, 2018

Sounds like you want semantic-release, but with monorepo-awareness. Unfortunately, there isn't great support for that scenario right now. It's something I would definitely like to get to, though.

@penx
Copy link

@penx penx commented Mar 19, 2018

lerna exec --no-private -- npm publish

This sounds like exactly what we need for our project but unfortunately there's still one major issue:

If some packages have been updated but others haven't, this will fail as npm publish will be run on all packages, even those that haven't changed, and throw an error:

You cannot publish over the previously published versions

@morgs32
Copy link

@morgs32 morgs32 commented Mar 19, 2018

@penx what about the package from @azu.
Could that help you?
#1056 (comment)

@azu
Copy link
Contributor

@azu azu commented Jul 22, 2018

Also, I've created @monorepo-utils/publish.
This script publish packages that are publish-able. (It wrap can-npm-publish.)

Just replace

$ lerna exec --bail=false can-npm-publish && npm publish

to

$ monorepo-utils-publish

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