原文：github.com/lerna/lerna…

在当前项目中发布包

安装lerna以访问lerna CLI。

使用

lerna publish              # 发布自上次发布以来已更改的包
lerna publish from-git     # 显式发布在当前提交中标记的包
lerna publish from-package # 显式发布注册表中不存在最新版本的包

运行时，此命令执行以下操作之一：

• 发布自上次发布以来更新的包（在幕后调用lerna版本）。
  • 这是Lerna2.x的遗留行为
• 发布在当前提交中标记的包（from-git）。
• 在最新提交中发布包，其中版本不在注册表中（from-package）。
• 发布在上一次提交中更新的包（及其依赖项）的未版本“canary”版本。

Lerna永远不会发布标记为private的包（"private": true 在 package.json中）

在所有发布操作期间，将在根和每个包中调用相应的生命周期脚本（除非被“-ignore scripts”禁用）。

有关发布作用域包、自定义注册表和自定义dist标记的详细信息，请查看每个包配置。

Positionals

bump from-git

除了lerna version支持的semver关键字外，lerna publish还支持from git关键字。这将识别由lerna版本标记的包并将它们发布到npm。这在CI场景中非常有用，在这种情况下，您希望手动增加版本，但通过自动化流程一致地发布包内容。

bump from-package

与from git关键字类似，但要发布的包列表是通过检查每个包来确定的 package.json并确定注册表中是否不存在任何包版本。注册表中不存在的任何版本都将被发布。当以前的lerna发布未能将所有包发布到注册表时，这很有用。

选项

除了以下选项外，lerna publish还支持lerna version提供的所有选项：

--canary

lerna publish --canary
# 1.0.0 => 1.0.1-alpha.0+${SHA} 包自上次提交以来已更改
# 随后的canary发布将生成1.0.1-alpha.1+${SHA}等

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

# 以下是等效的：
lerna publish --canary minor
lerna publish --canary preminor
# 1.0.0 => 1.1.0-alpha.0+${SHA}

使用此标志运行时，lerna publish将以更细粒度的方式（每次提交）发布包。在发布到npm之前，它通过获取当前版本，将其转发到下一个次要版本，添加提供的meta后缀（默认为alpha）并附加当前gitsha（例如：1.0.0变成1.1.0-alpha.0+81e3b443）来创建新的version标记。

如果您在CI中发布了来自多个活动开发分支的canary发行版，建议根据每个分支自定义--preid和--dist标记，以避免版本冲突。

此标志的预期用例是按提交级别发布或每夜发布一次。

--contents

要发布的子目录。必须应用于所有包，并且必须包含package.json文件。包生命周期仍将在原始叶目录中运行。您可能应该使用其中一个生命周期（prepare、prepublishly或prepack）来创建子目录等等。

如果你喜欢不必要的复杂出版，这会给你带来快乐。

lerna publish --contents dist
#发布每个Lerna托管叶包的“dist”子文件夹

注意：您应该等到发布后生命周期阶段（根目录或叶目录）清理这个生成的子目录package.json在包上载期间使用（后打包后）。

--dist-tag

lerna publish --dist-tag next

使用此标志运行时，lerna publish将使用给定的npm dist标记（默认为latest）发布到npm。

此选项可用于在非最新dist标记下发布预发行版或beta版，帮助用户避免自动升级到预发行版质量代码。

注意：最新的标记是当用户运行npm install my package时使用的标记。要安装其他标记，用户可以运行npm install my-package@prerelease.

--git-head

打包tarball时显式SHA设置为清单上的gitHead，仅允许使用from package positional。

例如，当从AWS CodeBuild（git不可用）发布时，可以使用此选项传递要用于此包元数据的适当环境变量：

lerna publish from-package --git-head ${CODEBUILD_RESOLVED_SOURCE_VERSION}

在所有其他情况下，此值都是从本地git命令派生的。

--graph-type <all|dependencies>

设置在构建包图形时使用哪种依赖关系。默认值是dependencies，因此只有在包的依赖项部分中列出的包package.json包括在内。在构造包图和确定拓扑顺序时，传递all以同时包含dependencies和devdependence。

当使用传统的peer+dev依赖项对时，应该将此选项配置为all，这样对等方总是在其依赖项之前发布。

lerna publish --graph-type all

通过配置lerna.json：

{
  "command": {
    "publish": {
      "graphType": "all"
    }
  }
}

--ignore-scripts

当传递时，此标志将禁用lerna发布期间运行的生命周期脚本。

--ignore-prepublish

传递时，此标志将禁止在lerna发布期间运行不推荐使用的预发布脚本。

--legacy-auth

当发布需要身份验证的包时，但是您使用的是内部托管的NPM注册表，该注册表仅使用旧版的Base64版本用户名：密码。这与NPM publish _auth标志相同。

lerna publish --legacy-auth aGk6bW9t

--no-git-reset

默认情况下，lerna publish确保对工作树的任何更改都已重置。

要避免这种情况，请传递--no git reset。当作为CI管道的一部分与--canary标志一起使用时，这一点尤其有用。例如package.json可能需要在随后的CI管道步骤（如Docker构建）中使用已被转发的版本号。

lerna publish --no-git-reset

--no-granular-pathspec

默认情况下，lerna publish将尝试（如果启用）git只签出在发布过程中临时修改的叶包清单。这就产生了相当于git checkout -- packages/*/package.json，但完全适应了变化。

如果你知道你需要不同的行为，你就会明白：通过--no-granular-pathspec 使git 命令是字面上的git checkout -- 。。。通过选择此路径规范，必须正确忽略所有故意未更新的内容。

在lerna.json中配置此选项最有意义，因为你真的不想把事情搞砸：

{
  "version": "independent",
  "granularPathspec": false
}

根级配置是有意的，因为这也涵盖了lerna版本中同名的选项。

--no-verify-access

默认情况下，lerna将验证登录的npm用户对即将发布的包的访问权限。传递此标志将禁用该检查。

如果您使用的是不支持npm access ls包的第三方注册表，则需要传递此标志（或command.publish.verifyAccess为false在lerna.json中).

请谨慎使用

--otp

发布需要双因素身份验证的包时，可以使用--otp:

lerna publish --otp 123456

请记住，一次性密码在生成后30秒内过期。如果在发布操作期间过期，则在继续之前，将在提示中请求刷新值。

--preid

与同名的lerna version选项不同，此选项只适用于--canary version计算。

lerna publish --canary
# 使用下一个语义预发布版本，例如。
# 1.0.0 => 1.0.1-alpha.0

lerna publish --canary --preid next
# 使用具有特定预发布标识符的下一个语义预发布版本，例如。
# 1.0.0 => 1.0.1-next.0

使用此标志运行时，lerna publish--canary将使用指定的prerelease标识符递增prejor、preminor、prepatch或prerelease semver bumps。

--pre-dist-tag

lerna publish --pre-dist-tag next

与--dist标记的工作原理相同，但只适用于使用预发布版本发布的包。

--registry

使用此标志运行时，转发的npm命令将使用包的指定注册表。

如果您不想在所有package.json中设置私有注册中心时，这是比较有用的。

--tag-version-prefix

此选项允许提供自定义前缀，而不是默认前缀：v。

请记住，如果拆分lerna version和lerna publish，则需要将其传递给两个命令：

# locally
lerna version --tag-version-prefix=''

# on ci
lerna publish from-git --tag-version-prefix=''

您也可以在lerna.json，同时应用于两个命令：

{
  "tagVersionPrefix": "",
  "packages": ["packages/*"],
  "version": "independent"
}

--temp-tag

传递时，此标志将更改默认发布过程，方法是首先将所有更改的包发布到临时dist标记（lerna temp），然后将新版本移动到由--dist tag（默认最新）配置的dist标记。

这通常是不必要的，因为默认情况下，Lerna将按拓扑顺序（所有依赖项在依赖项之前）发布包。

--yes

lerna publish --canary --yes
# 跳过是否确实要发布上述更改？`

使用此标志运行时，lerna publish将跳过所有确认提示。在连续集成（CI）中非常有用，可自动响应发布确认提示。

Lifecycle Scripts

// prepublish:      Run BEFORE the package is packed and published.
// prepare:         Run BEFORE the package is packed and published, AFTER prepublish, BEFORE prepublishOnly.
// prepublishOnly:  Run BEFORE the package is packed and published, ONLY on npm publish.
// prepack:     Run BEFORE a tarball is packed.
// postpack:    Run AFTER the tarball has been generated and moved to its final destination.
// publish:     Run AFTER the package is published.
// postpublish: Run AFTER the package is published.

Lerna will run npm lifecycle scripts during lerna publish in the following order:

• If versioning implicitly, run all version lifecycle scripts
• Run prepublish lifecycle in root, if enabled
• Run prepare lifecycle in root
• Run prepublishOnly lifecycle in root
• Run prepack lifecycle in root
• For each changed package, in topological order (all dependencies before dependents):
  • Run prepublish lifecycle, if enabled
  • Run prepare lifecycle
  • Run prepublishOnly lifecycle
  • Run prepack lifecycle
  • Create package tarball in temp directory via JS API
  • Run postpack lifecycle
• Run postpack lifecycle in root
• For each changed package, in topological order (all dependencies before dependents):
  • Publish package to configured registry via JS API
  • Run publish lifecycle
  • Run postpublish lifecycle
• Run publish lifecycle in root
  • To avoid recursive calls, don't use this root lifecycle to run lerna publish
• Run postpublish lifecycle in root
• Update temporary dist-tag to latest, if enabled