Research
Security News
Quasar RAT Disguised as an npm Package for Detecting Vulnerabilities in Ethereum Smart Contracts
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
@lerna/publish
Advanced tools
@lerna/publish
Publish packages in the current project
$ lerna publish
Publish packages in the current Lerna project. When run, this command does the following:
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.
More specifically, this command will:
lerna changed
to determine which packages need to be published.version
key in lerna.json
.package.json
of all updated packages to their new versions.Lerna won't publish packages which are marked as private (
"private": true
in thepackage.json
).
Note: to publish scoped packages, you need to add the following to each package.json
:
"publishConfig": {
"access": "public"
}
--exact
$ lerna publish --exact
When run with this flag, publish
will specify updated dependencies in updated packages exactly (with no punctuation), instead of as semver compatible (with a ^
).
For more information, see the package.json dependencies documentation.
--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.
--npm-client <client>
Must be an executable that knows how to publish packages to an npm registry.
The default --npm-client
is npm
.
$ lerna publish --npm-client=yarn
May also be configured in lerna.json
:
{
"command": {
"publish": {
"npmClient": "yarn"
}
}
}
--npm-tag <dist-tag>
$ lerna publish --npm-tag=next
When run with this flag, 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.
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
.
--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 default dist-tag (latest
).
This is not generally necessary, as Lerna will publish packages in topological order (all dependencies before dependents) by default.
--canary
$ 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
$ lerna publish --conventional-commits
When run with this flag, publish
will use the Conventional Commits Specification to determine the version bump and generate CHANGELOG
--changelog-preset
$ lerna publish --conventional-commits --changelog-preset angular-bitbucket
By default, the changelog preset is set to angular
.
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>
$ 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
$ 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 bylerna publish
.
--skip-npm
$ 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]
$ 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 agit diff
change to be updated.
--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.
Useful in Continuous integration (CI) to automatically answer the publish confirmation prompt.
--cd-version
$ 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
$ 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.
--repo-version
$ 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
.
$ 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 and/or 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:
{
"command": {
"publish": {
"message": "chore(release): publish %s"
}
}
}
--amend
$ 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) 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.
{
"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.
{
"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.
$ lerna publish --allow-branch hotfix/oops-fix-the-thing
3.0.0-rc.0 (2018-07-27)
--exact
option to lerna add
(#1478) (346d156), closes #1470rawPackageList
getter (0ad5faf)--amend
flag (#1422) (ef5f0db)$PKGDIR/scripts/{pre,post}publish.js
lifecycles are now opt-in instead of automatic. Pass --require-scripts
explicitly to restore previous functionality.this.packages
no longer exists in Command subclasses, use this.packageGraph.rawPackageList
<a name="3.0.0-beta.21"></a>
FAQs
Publish packages in the current project
The npm package @lerna/publish receives a total of 375,760 weekly downloads. As such, @lerna/publish popularity was classified as popular.
We found that @lerna/publish demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.