Skip to content

Commit

Permalink
feat: Split lerna version from of lerna publish (#1522)
Browse files Browse the repository at this point in the history 
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
  • Loading branch information
@evocateur
evocateur committed Jul 27, 2018
1 parent 1ab24c1 commit 8b97394
Show file tree
Hide file tree
Showing 81 changed files with 3,118 additions and 2,406 deletions.
6 changes: 3 additions & 3 deletions commands/changed/command.js
View file
@@ -1,6 +1,6 @@
"use strict";

const publishOptions = require("@lerna/publish/command").builder;
const versionOptions = require("@lerna/version/command").builder;

/**
* @see https://github.com/yargs/yargs/blob/master/docs/advanced.md#providing-a-command-module
Expand All @@ -9,10 +9,10 @@ exports.command = "changed";

exports.aliases = ["updated"];

exports.describe = "Check which packages have changed since the last publish";
exports.describe = "Check which packages have changed since the last release";

exports.builder = yargs =>
publishOptions(yargs).options({
versionOptions(yargs, true).options({
json: {
describe: "Show information in JSON format",
group: "Command Options:",
Expand Down
3 changes: 2 additions & 1 deletion commands/changed/index.js
View file
Expand Up @@ -14,7 +14,8 @@ function factory(argv) {

class ChangedCommand extends Command {
get otherCommandConfigs() {
return ["publish"];
// back-compat
return ["version", "publish"];
}

initialize() {
Expand Down
2 changes: 1 addition & 1 deletion commands/changed/package.json
View file
Expand Up @@ -34,7 +34,7 @@
"@lerna/collect-updates": "file:../../utils/collect-updates",
"@lerna/command": "file:../../core/command",
"@lerna/output": "file:../../utils/output",
"@lerna/publish": "file:../publish",
"@lerna/version": "file:../version",
"chalk": "^2.3.1"
}
}
291 changes: 57 additions & 234 deletions commands/publish/README.md
View file
Expand Up @@ -5,26 +5,18 @@
## Usage

```sh
$ lerna publish
lerna publish # publish packages that have changed since the last release
lerna publish from-git # explicitly publish packages tagged in current commit
```

Publish packages in the current Lerna project. When run, this command does the following:
When run, this command does one of the following things:

Creates a new release of the packages that have been updated.
Prompts for a new version.
Creates a new git commit/tag in the process of publishing to npm.
* Publish packages updated since the last release (calling [`lerna version`](https://github.com/lerna/lerna/tree/master/commands/version#readme) behind the scenes).
* This is the legacy behavior of lerna 2.x
* Publish packages tagged in the current commit (`from-git`).
* Publish an unversioned "canary" release of packages (and their dependents) updated in the previous commit.

More specifically, this command will:

1. Run the equivalent of `lerna changed` to determine which packages need to be published.
2. If necessary, increment the `version` key in `lerna.json`.
3. Update the `package.json` of all updated packages to their new versions.
4. Update all dependencies of the updated packages with the new versions, specified with a [caret (^)](https://docs.npmjs.com/files/package.json#dependencies).
5. Create a new git commit and tag for the new version.
6. Make sure the updated packages contain license files before publishing. Use root license file if the packages do not contain their own.
7. Publish updated packages to npm.

> Lerna won't publish packages which are marked as private (`"private": true` in the `package.json`).
> Lerna will never publish packages which are marked as private (`"private": true` in the `package.json`).
**Note:** to publish scoped packages, you need to add the following to each `package.json`:

Expand All @@ -34,33 +26,54 @@ More specifically, this command will:
}
```

## Positionals

### bump `from-git`

In addition to the semver keywords supported by [`lerna version`](https://github.com/lerna/lerna/tree/master/commands/version#positionals),
`lerna publish` also supports the `from-git` keyword.
This will identify packages tagged by `lerna version` and publish them to npm.
This is useful in CI scenarios where you wish to manually increment versions,
but have the package contents themselves consistently published by an automated process.

## Options

### `--exact`
`lerna publish` supports all of the options provided by [`lerna version`](https://github.com/lerna/lerna/tree/master/commands/version#options) in addition to the following:

```sh
$ lerna publish --exact
```
* [`--canary`](#--canary)
* [`--npm-client <client>`](#--npm-client-client)
* [`--npm-tag <dist-tag>`](#--npm-tag-dist-tag)
* [`--registry <url>`](#--registry-url)
* [`--temp-tag`](#--temp-tag)
* [`--yes`](#--yes)

When run with this flag, `publish` will specify updated dependencies in updated packages exactly (with no punctuation), instead of as semver compatible (with a `^`).
### `--canary`

For more information, see the package.json [dependencies](https://docs.npmjs.com/files/package.json#dependencies) documentation.
```sh
lerna publish --canary
# 1.0.0 => 1.0.1-alpha.0+${SHA} of packages changed since the previous commit
# a subsequent canary publish will yield 1.0.1-alpha.1+${SHA}, etc

### `--registry <url>`
lerna publish --canary --preid beta
# 1.0.0 => 1.0.1-beta.0+${SHA}

When run with this flag, forwarded npm commands will use the specified registry for your package(s).
# The following are equivalent:
lerna publish --canary minor
lerna publish --canary preminor
# 1.0.0 => 1.1.0-alpha.0+${SHA}
```

This is useful if you do not want to explicitly set up your registry
configuration in all of your package.json files individually when e.g. using
private registries.
When run with this flag, `lerna publish` publishes packages in a more granular way (per commit). Before publishing to npm, it creates the new `version` tag by taking the current `version`, bumping it to the next _minor_ version, adding the provided meta suffix (defaults to `alpha`) and appending the current git sha (ex: `1.0.0` becomes `1.1.0-alpha.81e3b443`).

> The intended use case for this flag is a per commit level release or nightly release.
### `--npm-client <client>`

Must be an executable that knows how to publish packages to an npm registry.
The default `--npm-client` is `npm`.

```sh
$ lerna publish --npm-client=yarn
lerna publish --npm-client yarn
```

May also be configured in `lerna.json`:
Expand All @@ -78,16 +91,24 @@ May also be configured in `lerna.json`:
### `--npm-tag <dist-tag>`

```sh
$ lerna publish --npm-tag=next
lerna publish --npm-tag next
```

When run with this flag, `publish` will publish to npm with the given npm [dist-tag](https://docs.npmjs.com/cli/dist-tag) (defaults to `latest`).
When run with this flag, `lerna publish` will publish to npm with the given npm [dist-tag](https://docs.npmjs.com/cli/dist-tag) (defaults to `latest`).

This option can be used to publish a [`prerelease`](http://carrot.is/coding/npm_prerelease) or `beta` version.
This option can be used to publish a [`prerelease`](http://carrot.is/coding/npm_prerelease) or `beta` version under a non-`latest` dist-tag, helping consumers avoid automatically upgrading to prerelease-quality code.

> Note: the `latest` tag is the one that is used when a user runs `npm install my-package`.
> To install a different tag, a user can run `npm install my-package@prerelease`.
### `--registry <url>`

When run with this flag, forwarded npm commands will use the specified registry for your package(s).

This is useful if you do not want to explicitly set up your registry
configuration in all of your package.json files individually when e.g. using
private registries.

### `--temp-tag`

When passed, this flag will alter the default publish process by first publishing
Expand All @@ -97,216 +118,18 @@ new version(s) to the default [dist-tag](https://docs.npmjs.com/cli/dist-tag) (`
This is not generally necessary, as Lerna will publish packages in topological
order (all dependencies before dependents) by default.

### `--canary`

```sh
$ lerna publish --canary
$ lerna publish --canary=beta
```

When run with this flag, `publish` publishes packages in a more granular way (per commit). Before publishing to npm, it creates the new `version` tag by taking the current `version`, bumping it to the next _minor_ version, adding the provided meta suffix (defaults to `alpha`) and appending the current git sha (ex: `1.0.0` becomes `1.1.0-alpha.81e3b443`).

> The intended use case for this flag is a per commit level release or nightly release.
### `--conventional-commits`

```sh
$ lerna publish --conventional-commits
```

When run with this flag, `publish` will use the [Conventional Commits Specification](https://conventionalcommits.org/) to [determine the version bump](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-recommended-bump) and [generate CHANGELOG](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-cli)

### `--changelog-preset`

```sh
$ lerna publish --conventional-commits --changelog-preset angular-bitbucket
```

By default, the changelog preset is set to [`angular`](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular#angular-convention).
In some cases you might want to change either use a another preset or a custom one.

Presets are names of built-in or installable configuration for conventional changelog.
Presets may be passed as the full name of the package, or the auto-expanded suffix
(e.g., `angular` is expanded to `conventional-changelog-angular`).

### `--git-remote <name>`

```sh
$ lerna publish --git-remote upstream
```

When run with this flag, `publish` will push the git changes to the specified remote instead of `origin`.

### `--skip-git`

```sh
$ lerna publish --skip-git
```

When run with this flag, `publish` will publish to npm without generating a git commit, tag, or pushing changes to a remote.

> NOTE: This option **does not** restrict _all_ git commands from being executed. `git` is still required by `lerna publish`.
### `--skip-npm`

```sh
$ lerna publish --skip-npm
```

When run with this flag, `publish` will update all `package.json` package
versions and dependency versions, but it will not actually publish the
packages to npm.

This flag can be combined with `--skip-git` to _just_ update versions and
dependencies, without committing, tagging, pushing or publishing.

### `--force-publish [package-names-or-globs]`

```sh
$ lerna publish --force-publish=package-2,package-4
# force publish all packages
$ lerna publish --force-publish=*
# same as previous
$ lerna publish --force-publish
```

When run with this flag, `publish` will force publish the specified packages (comma-separated) or all packages using `*`.

> This will skip the `lerna changed` check for changed packages and forces a package that didn't have a `git diff` change to be updated.
### `--yes`

```sh
$ lerna publish --canary --yes
lerna publish --canary --yes
# skips `Are you sure you want to publish the above changes?`
```

When run with this flag, `publish` will skip all confirmation prompts.
When run with this flag, `lerna publish` will skip all confirmation prompts.
Useful in [Continuous integration (CI)](https://en.wikipedia.org/wiki/Continuous_integration) to automatically answer the publish confirmation prompt.

### `--cd-version`
## Deprecated Options

```sh
$ lerna publish --cd-version (major | minor | patch | premajor | preminor | prepatch | prerelease)
# uses the next semantic version(s) value and this skips `Select a new version for...` prompt
```

When run with this flag, `publish` will skip the version selection prompt (in independent mode) and use the next specified semantic version.
You must still use the `--yes` flag to avoid all prompts. This is useful when build systems need to publish without command prompts. Works in both normal and independent modes.

If you have any packages with a prerelease version number (e.g. `2.0.0-beta.3`) and you run `lerna publish` with `--cd-version` and a non-prerelease version increment (major / minor / patch), it will publish those packages in addition to the packages that have changed since the last release.

### `--preid`

```sh
$ lerna publish --cd-version=prerelease
# uses the next semantic prerelease version, e.g.
# 1.0.0 => 1.0.0-0

$ lerna publish --cd-version=prepatch --preid=next
# uses the next semantic prerelease version with a specific prerelease identifier, e.g.
# 1.0.0 => 1.0.1-next.0
```

When run with this flag, `lerna publish --cd-version` will
increment `premajor`, `preminor`, `prepatch`, or `prerelease`
versions using the specified [prerelease identifier](http://semver.org/#spec-item-9).

### `--repo-version`

```sh
$ lerna publish --repo-version 1.0.1
# applies version and skips `Select a new version for...` prompt
```

When run with this flag, `publish` will skip the version selection prompt and use the specified version.
Useful for bypassing the user input prompt if you already know which version to publish.

### `--message <msg>`

This option is aliased to `-m` for parity with `git commit`.

```sh
$ lerna publish -m "chore(release): publish %s"
# commit message = "chore(release): publish v1.0.0"

$ lerna publish -m "chore(release): publish %v"
# commit message = "chore(release): publish 1.0.0"

$ lerna publish -m "chore(release): publish" --independent
# commit message = "chore(release): publish
#
# - package-1@3.0.1
# - package-2@1.5.4"
```

When run with this flag, `publish` will use the provided message when committing the version updates
for publication. Useful for integrating lerna into projects that expect commit messages to adhere
to certain guidelines, such as projects which use [commitizen](https://github.com/commitizen/cz-cli) and/or [semantic-release](https://github.com/semantic-release/semantic-release).

If the message contains `%s`, it will be replaced with the new global version version number prefixed with a "v".
If the message contains `%v`, it will be replaced with the new global version version number without the leading "v".
Note that this only applies when using the default "fixed" versioning mode, as there is no "global" version when using `--independent`.

This can be configured in lerna.json, as well:

```json
{
"command": {
"publish": {
"message": "chore(release): publish %s"
}
}
}
```

### `--amend`

```sh
$ lerna publish --amend
# commit message is retained, and `git push` is skipped.
```

When run with this flag, `publish` will perform all changes on the current commit, instead of adding a new one.
This is useful during [Continuous integration (CI)](https://en.wikipedia.org/wiki/Continuous_integration) to reduce the number of commits in the project's history.

In order to prevent unintended overwrites, this command will skip `git push`.

### `--allow-branch <glob>`

A whitelist of globs that match git branches where `lerna publish` is enabled.
It is easiest (and recommended) to configure in `lerna.json`, but it is possible to pass as a CLI option as well.

```json
{
"command": {
"publish": {
"allowBranch": "master"
}
}
}
```

With the configuration above, the `lerna publish` will fail when run from any branch other than `master`.
It is considered a best-practice to limit `lerna publish` to the primary branch alone.

```json
{
"command": {
"publish": {
"allowBranch": ["master", "feature/*"]
}
}
}
```

With the preceding configuration, `lerna publish` will be allowed in any branch prefixed with `feature/`.
Please be aware that generating git tags in feature branches is fraught with potential errors as the branches are merged into the primary branch. If the tags are "detached" from their original context (perhaps through a squash merge or a conflicted merge commit), future `lerna publish` executions will have difficulty determining the correct "diff since last release."

It is always possible to override this "durable" config on the command-line.
Please use with caution.

```sh
$ lerna publish --allow-branch hotfix/oops-fix-the-thing
```
### `--skip-npm`

Call [`lerna version`](https://github.com/lerna/lerna/tree/master/commands/version#readme) directly, instead.
3 changes: 3 additions & 0 deletions commands/publish/__tests__/__fixtures__/snake-independent/lerna.json
View file
@@ -0,0 +1,3 @@
{
"version": "independent"
}

0 comments on commit 8b97394

Please sign in to comment.