Publish packages in the current project
$ npm install @lerna/publish
@lerna/publish
Publish packages in the current project
lerna publish # publish packages that have changed since the last release
lerna publish from-git # explicitly publish packages tagged in the current commit
lerna publish from-package # explicitly publish packages where the latest version is not present in the registry
When run, this command does one of the following things:
lerna version
behind the scenes).
from-git
).from-package
).Lerna will never publish packages which are marked as private (
"private": true
in thepackage.json
).
Check out Per-Package Configuration for more details about publishing scoped packages, custom registries, and custom dist-tags.
from-git
In addition to the semver keywords supported by lerna version
,
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.
from-package
Similar to the from-git
keyword except the list of packages to publish is determined by inspecting each package.json
and determining if any package version is not present in the registry. Any versions not present in the registry will
be published.
This is useful when a previous lerna publish
failed to publish all packages to the registry.
lerna publish
supports all of the options provided by lerna version
in addition to the following:
--canary
--contents <dir>
--dist-tag <tag>
--no-git-reset
--no-verify-access
--preid
--registry <url>
--temp-tag
--yes
--canary
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
lerna publish --canary --preid beta
# 1.0.0 => 1.0.1-beta.0+${SHA}
# The following are equivalent:
lerna publish --canary minor
lerna publish --canary preminor
# 1.0.0 => 1.1.0-alpha.0+${SHA}
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.0+81e3b443
).
If you have publish canary releases from multiple active development branches in CI,
it is recommended to customize the --preid
and --dist-tag <tag>
on a per-branch basis to avoid clashing versions.
The intended use case for this flag is a per commit level release or nightly release.
--contents <dir>
Subdirectory to publish. Must apply to ALL packages, and MUST contain a package.json file.
Package lifecycles will still be run in the original leaf directory.
You should probably use one of those lifecycles (prepare
, prepublishOnly
, or prepack
) to create the subdirectory and whatnot.
If you're into unnecessarily complicated publishing, this will give you joy.
lerna publish --contents dist
# publish the "dist" subfolder of every Lerna-managed leaf package
--dist-tag <tag>
lerna publish --dist-tag next
When run with this flag, lerna publish
will publish to npm with the given npm dist-tag (defaults to latest
).
This option can be used to publish a 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 runsnpm install my-package
. To install a different tag, a user can runnpm install my-package@prerelease
.
--no-git-reset
By default, lerna publish
ensures any changes to the working tree have been reset.
To avoid this, pass --no-git-reset
. This can be especially useful when used as part of a CI pipeline in conjunction with the --canary
flag. For instance, the package.json
version numbers which have been bumped may need to be used in subsequent CI pipeline steps (such as Docker builds).
lerna publish --no-git-reset
--no-verify-access
By default, lerna
will verify the logged-in npm user's access to the packages about to be published. Passing this flag will disable that check.
If you are using a third-party registry that does not support npm access ls-packages
, you will need to pass this flag (or set command.publish.verifyAccess
to false
in lerna.json).
Please use with caution
--preid
Unlike the lerna version
option of the same name, this option only applies to --canary
version calculation.
lerna publish --canary
# uses the next semantic prerelease version, e.g.
# 1.0.0 => 1.0.1-alpha.0
lerna publish --canary --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 --canary
will increment premajor
, preminor
, prepatch
, or prerelease
semver
bumps using the specified prerelease identifier.
--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
all changed packages to a temporary dist-tag (lerna-temp
) and then moving the
new version(s) to the dist-tag configured by --dist-tag
(default latest
).
This is not generally necessary, as Lerna will publish packages in topological order (all dependencies before dependents) by default.
--yes
lerna publish --canary --yes
# skips `Are you sure you want to publish the above changes?`
When run with this flag, lerna publish
will skip all confirmation prompts.
Useful in Continuous integration (CI) to automatically answer the publish confirmation prompt.
--skip-npm
Call lerna version
directly, instead.
A leaf package can be configured with special publishConfig
that in certain circumstances changes the behavior of lerna publish
.
publishConfig.access
To publish packages with a scope (e.g., @mycompany/rocks
), you must set access
:
"publishConfig": {
"access": "public"
}
If this field is set for a package without a scope, it will fail.
If you want your scoped package to remain private (i.e., "restricted"
), there is no need to set this value.
Note that this is not the same as setting "private": true
in a leaf package; if the private
field is set, that package will never be published under any circumstances.
publishConfig.registry
You can customize the registry on a per-package basis by setting registry
:
"publishConfig": {
"registry": "http://my-awesome-registry.com/"
}
--registry
applies globally, and in some cases isn't what you want.publishConfig.tag
You can customize the dist-tag on a per-package basis by setting tag
:
"publishConfig": {
"tag": "flippin-sweet"
}
--dist-tag
will overwrite this value.--canary
is passed.© 2010 - cnpmjs.org x YWFE | Home | YWFE