Lerna — multi package storage management tool (1)

lerna

I’ve been watching it recentlyvue-cliIn the source code part of, I noticed that multiple packages were maintained in this warehouse. I was curious about how he managed these packages in a repo.

Our group is now using the component library to maintain the business code shared between projects. There are two component libraries, which are dependent on each othernpm linkIn this way, the performance is not good, and the problem of jamming often occurs. In addition, some time ago, the group shared vue3 and also mentioned lerna, so they decided to carefully investigate this tool to help optimize the next component library.

lernaThe document is very detailed, because it’s all in English. Considering the reading problem, I first ran several demos myself, and then did a Chinese translation. I’ll write a special article laterLerna actual combat

demo

What does lerna do?

Lerna is a tool that optimizes the workflow of using GIT and NPM to manage multi package repositories.

background

1. Divide a large package into small ones for sharing and debugging

2. In multiple git repositories, changes are easily confused and difficult to track

3. Maintenance and testing in multiple git warehouses is tedious

Two working modes

Fixed/Locked mode (default)

Vue and Babel all use this method. When publishing, all package versions are updated, and the package versions are consistent. The version number is maintained in the lerna.jon In the version of

Independent mode

lerna init --independent

Independent mode, each package can have its own version number. The version number is maintained in the respective package.json In the version of. The package that has been changed, as well as the recommended version number or custom version number will be prompted before each release. This way is more flexible than the first one

Initialize project

NPM install - G lerna // this is a global installation. It can also be installed as a project development dependency. Using global is convenient for later use of the command line

mkdir lerna-repo

cd lerna-repo

Lerna init // initialize a lerna project structure. If you want each package to use a separate version number, you can add - I | -- independent

Standard lerna directory structure

• There is one under each individual bag package.json file
• If the package name has a scope, for example, @ test / lerna, package.json “Publishconfig”: {“access”: “public”} must be configured in “

my-lerna-repo/

    package.json

    lerna.json

    LICENSE

    packages/

        package-1/

            package.json

        package-2/

            package.json

Enable yarn workspaces (highly recommended)

Workspaces can only be enabled in private projects.

The default is NPM, and each sub package has its own node_ Modules. After setting in this way, all the dependencies will be promoted to the top node_ Modules, and in node_ Link local package in modules for debugging

be careful: you must be a private project to open workspaces

// package.json

"private": true,

"workspaces": [

    "packages/*"

],
 

// lerna.json

 
"useWorkspaces": true,

"npmClient": "yarn",

hoist:Extract common root dependentnode_moduels, which can be customized. The rest depends on the installationpackage/node_modelesThe executable must be installed in thepackage/node_modeles。

workspaces:All dependencies are in the same directorynode_moduels, except for the executable

Common commands

lerna init

Initialize lerna project

• -i. — independent independent version mode

[lerna create <name> [loc]](https://github.com/lerna/lern…

Create a packcage

• --accessWhen usingscope packageWhen (@ qinzhiwei / lerna), you need to set this option. The optional values are: “public”, “restricted”
• --binCreate executable file--bin <executableName>
• --descriptionDescription [string]
• --dependenciesDependency, comma separated [array]
• --es-moduleInitialize a converted es module [Boolean]
• --homepageSource address [string]
• --keywordsNumber of key words [array]
• --licenseProtocol string
• --privatePrivate warehouse or not
• --registrySource [string]
• --tagPublished label [string]
• -y, --yesSkip all prompts and use the default configuration [Boolean]

lerna add

Add local or remote dependencies for the matching package. Only one dependency can be added at a time

$ lerna add <package>[@version] [--dev] [--exact] [--peer]

What to do when running this command:

1. Add a dependency for the matched package
2. Change the package.json Dependency properties in

Command Options

What are the following optionsnpm installTime is the same

• --dev
• --exact
• --peerPeer dependencies, which need to be installed in the project at the same time to use the package
• --registry <url>
• --no-bootstrapskiplerna bootstrap, only when the package.json Properties in

All filtering options are supported

Examples

# Adds the module-1 package to the packages in the 'prefix-' prefixed folders

lerna add module-1 packages/prefix-*

  

# Install module-1 to module-2

lerna add module-1 --scope=module-2

  

# Install module-1 to module-2 in devDependencies

lerna add module-1 --scope=module-2 --dev

  

# Install module-1 to module-2 in peerDependencies

lerna add module-1 --scope=module-2 --peer

  

# Install module-1 in all modules except module-1

lerna add module-1

  

# Install babel-core in all modules

lerna add babel-core

lerna bootstrap

Link local packages together and install dependencies

The following four things are done to execute the command:

1. Install dependencies for each package

2. Link the interdependent libraries to a specific directory. For example, if lerna1 depends on lerna2 and the version is the local version, it will be displayed in the node_ The local project is linked in modules. If the version does not meet the requirements, it needs to be installed according to the normal dependency

3. Execute in bootstrapped packagesnpm run prepublish

4. Execute in bootstrapped packagesnpm run prepare

Command Options

• --hoistMatch [glob] dependency promotion to root directory [default: ‘* *’], dependency containing executable binary file or must be installed in the node of current package_ Modules to ensure the NPM script running
• --nohoistJust the opposite of the above [string]
• --ignore-prepublishNo longer run the script [Boolean] in the prepublish lifecycle in bootstrapped packages
• --ignore-scriptsNo longer run any scripts in the lifecycle in bootstrapped packages
• --npm-clientNPM client used (NPM, yarn, pnpm,…) [string]
• --registrySource [string]
• --strictWarning is not allowed in bootstrap process to avoid spending more time or causing other problems [Boolean]
• --use-workspacesWorkspaces mode with yarn enabled [Boolean]
• --force-localForce local sibling links regardless of version range match [Boolean]
• --contentsSubdirectories are used as the source of any links. Must apply to all package strings

lerna link

Connect locally interdependent packages to each other. For example, if lerna1 depends on lerna2 and the version number is the local lerna2, the node will be created under lerna1_ Building soft link in modules to point to lerna2

Command Options

• –Force local links local packages whether they meet version requirements or not

//Specifies the soft link to a specific directory of the package

"publishConfig": {

    "Directory": "dist" // when bootstrapping, the dist directory under the soft chain package package package-1 / dist = > node_ modules/package-1

}

lerna list

List subcommand

• lerna ls: equivalent tolerna listItself, output all packages under the project
• lerna ll: output the name, current version and location of all packages under the project
• lerna la: output the name, current version and location of all packages under the project, including private package

Command Options

• --json
• --ndjson
• -a, --all
• -l, --long
• -p, --parseable
• --toposort
• --graph

All filtering options are supported

--json

Display in the form of JSON

$ lerna ls --json

[

    {

        "name": "package-1",

        "version": "1.0.0",

        "private": false,

        "location": "/path/to/packages/pkg-1"

    },

    {

        "name": "package-2",

        "version": "1.0.0",

        "private": false,

        "location": "/path/to/packages/pkg-2"

    }

]

--ndjson

withnewline-delimited JSONDisplay information

$ lerna ls --ndjson

{"name":"package-1","version":"1.0.0","private":false,"location":"/path/to/packages/pkg-1"}

{"name":"package-2","version":"1.0.0","private":false,"location":"/path/to/packages/pkg-2"}

--all

Alias: -a

Show private package hidden by default

$ lerna ls --all

package-1

package-2

package-3 (private)

--long

Alias: -l

Displays the version, location, and name of the package

$ lerna ls --long

package-1 v1.0.1 packages/pkg-1

package-2 v1.0.2 packages/pkg-2

  

$ lerna ls -la

package-1 v1.0.1 packages/pkg-1

package-2 v1.0.2 packages/pkg-2

package-3 v1.0.3 packages/pkg-3 (private)

--parseable

Alias: -p

Displays the absolute path of the package

In --long output, each line is a :-separated list: <fullpath>:<name>:<version>[:flags..]

$ lerna ls --parseable

/path/to/packages/pkg-1

/path/to/packages/pkg-2

  

$ lerna ls -pl

/path/to/packages/pkg-1:package-1:1.0.1

/path/to/packages/pkg-2:package-2:1.0.2

  

$ lerna ls -pla

/path/to/packages/pkg-1:package-1:1.0.1

/path/to/packages/pkg-2:package-2:1.0.2

/path/to/packages/pkg-3:package-3:1.0.3:PRIVATE

--toposort

The packages are sorted in topological order (dependencies before dependencies), rather than lexically sorted by directory.

$ json dependencies <packages/pkg-1/package.json

{

    "pkg-2": "file:../pkg-2"

}

  

$ lerna ls --toposort

package-2

package-1

--graph

Display the dependency graph as an adjacency table in JSON formatadjacency list.

$ lerna ls --graph

{

    "pkg-1": [

        "pkg-2"

    ],

    "pkg-2": []

}

  

$ lerna ls --graph --all

{

    "pkg-1": [

       "pkg-2"

    ],

    "pkg-2": [

        "pkg-3"

    ],

    "pkg-3": [

        "pkg-2"

    ]

}

lerna changed

List the packages that have changed locally since the last release

be careful: lerna publishandlerna versionOflerna.jsonConfiguration has the same impactlerna changed. for examplecommand.publish.ignoreChanges.

Command Options

lerna changedsupportlerna lsAll tags for:

• --json
• --ndjson
• -a, --all
• -l, --long
• -p, --parseable
• --toposort
• --graph

Lerna does not supportFiltering optionsBecauselerna version or lerna publishFiltering options are not supported

lerna changedsupportlerna version(the others are irrelevant) filtering options:

• --conventional-graduate.
• --force-publish.
• --ignore-changes.
• --include-merged-tags.

lerna import

lerna import <path-to-external-repository>

Import the existing package into the lerna project. The previous original submission author can be retained, and the date and message will be retained.

be careful: if you want to introduce it in a new lerna, you must have at least one commit

Command Options

• --flattenHandling merge conflicts
• --destSpecifies the directory where the package is imported
• --preserve-commitKeep the original submitted information of the imported project

lerna clean

lerna clean

Remove all nodes under packages_ Modules will not be removed from the root directory

All filtering options are supported

lerna diff

View the changes of a package or all packages since the last release

$ lerna diff [package]

  

$ lerna diff

# diff a specific package

$ lerna diff package-name

Similar to lerna changed. This command runs git diff.

lerna exec

In each package, execute any command, use the break sign（--）Split command statement

Usage

$ lerna exec -- <command> [..args] # runs the command in all packages

$ lerna exec -- rm -rf ./node_modules

$ lerna exec -- protractor conf.js

Can passLERNA_PACKAGE_NAMEVariable to get the current package name:

$ lerna exec -- npm view $LERNA_PACKAGE_NAME

You can also pass theLERNA_ROOT_PATHGet the absolute path of the root directory:

$ lerna exec -- node $LERNA_ROOT_PATH/scripts/some-script.js

Command Options

All filtering options are supported

$ lerna exec --scope my-component -- ls -la

• –concurrenty

Use the given number for concurrent execution (unless specified)--parallel)。

The output is filtered by pipeline, and there is uncertainty.

If you want commands to be executed one by one, you can use the following methods:

$ lerna exec --concurrency 1 -- ls -la

• --stream

Output immediately from the child process, prefixed with the name of the package. This mode allows cross output:

$ lerna exec --stream -- babel src -d lib

• --parallel

and--streamVery similar. But the concurrency and sorting are completely ignored, and the given command or script is immediately run in all matching packages. Suitable for long-running processes. For example, in the listening statebabel src -d lib -w

$ lerna exec --parallel -- babel src -d lib -w

be careful:It is recommended to use the scope of command control package.

Because too many processes can be damagingshellThe stability of the system. For example, the maximum file descriptor limit

• --no-bail

# Run a command, ignoring non-zero (error) exit codes

$ lerna exec --no-bail <command>

By default, if there is an error in the command, the process will be refunded. Using this command will prohibit this behavior, skip the error correcting behavior, and continue to execute other commands

• --no-prefix

The name of the package is not displayed in the output

• --profile

Generate a JSON file, which can be downloaded from Chrome browser（devtools://devtools/bundled/devtools_app.html）View the performance analysis. By configuration--concurrentyYou can open a fixed number of child processes

$ lerna exec --profile -- <command>

be careful:Analyze only when topological sorting is enabled. Can’t compete with--parallel and --no-sortUsed together.

• --profile-location <location>

Set analysis file storage location

$ lerna exec --profile --profile-location=logs/profile/ -- <command>

lerna run

Run the NPM script in each package

usage method

$ lerna run <script> -- [..args] # runs npm run my-script in all packages that have it

$ lerna run test

$ lerna run build

  

# watch all packages and transpile on change, streaming prefixed output

$ lerna run --parallel watch

Command Options

• --npm-client <client>

set upnpmClient, default isnpm

$ lerna run build --npm-client=yarn

It can also be in thelerna.jsonto configure:

{

    "command": {

        "run": {

            "npmClient": "yarn"

        }

    }

}

• The rest are the samelerna exec

lerna version

Generate a new unique version number

Bumm version: when using GitHub like programs, upgrade the version number to a new unique value

usage method

Lerna version 1.0.1

Lerna version patch # semantic keyword

Lerna version # select from the prompts

When executed, the command does the following:

1. Identify the package that has changed since the last marked release. 2. Version prompt. 3. Modify the metadata of the package to reflect the new version, and run it properly in the root directory and each packagelifecycle scripts4. Submit changes on GIT and mark the submission（git commit & git tag）5. Submit to remote warehouse（git push)

Positionals

semver bump

lerna 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 this positional parameter is passed, lerna version will skip the version selection prompt and increment the version by that keyword.

You must still use the --yes flag to avoid all prompts.

Prerelease

If some packages are pre release versions (e.g2.0.0-beta.3）When you runlerna versionWhen matching with semantic version（major, minor, patch）, which will release the previous pre release version and the package cage that has changed since the last release.

For projects that use regular commit, you can use the following tags to manage pre release versions:

• --conventional-prerelease:The current release version is changed to the pre release version (even if the fixed mode is adopted, the package will be upgraded separately)
• --conventional-graduate:Upgrade the pre release version to the stable version (even if the fixed mode is adopted, the package will be upgraded separately)

When a package isAdvance versionThe above marks are not used, and thelerna version --conventional-commits, and will continue to upgrade the current package according to the pre released version.

Command Options

• --allow-branch
• --amend
• --changelog-preset
• --conventional-commits
• --conventional-graduate
• --conventional-prerelease
• --create-release
• --exact
• --force-publish
• --git-remote
• --ignore-changes
• --ignore-scripts
• --include-merged-tags
• --message
• --no-changelog
• --no-commit-hooks
• --no-git-tag-version
• --no-granular-pathspec
• --no-private
• --no-push
• --preid
• --sign-git-commit
• --sign-git-tag
• --force-git-tag
• --tag-version-prefix
• --yes

--allow-branch <glob>

A whitelist of globs that match git branches where lerna version is enabled.

It is easiest (and recommended) to configure in lerna.json, but it is possible to pass as a CLI option as well.

Settings can be calledlerna versionThe branch whitelist of the command can also be found in thelerna.jsonSet in

{

    "command": {

        "version": {

            "allowBranch": ["master", "beta/*", "feature/*"]

        }

    }

}

--amend

lerna version --amend

# commit message is retained, and `git push` is skipped.

By default, if there is uncommitted content in the staging area,lerna versionWill fail, need to save local content in advance. With this tag, the number of commit can be reduced, and the current change content can be changed once with this version. And it won’tgit push

--changelog-preset

lerna version --conventional-commits --changelog-preset angular-bitbucket

By default, changelog is set toangular. In some cases, you may need to use another preset or customization.

--conventional-commits

lerna version --conventional-commits

When running with this flag, the lerna version will use theTraditional commit specificationcomeDetermine versionAnd generateCHANGELOG.md。

afferent--no-changelogWill prevent build or updateCHANGELOG.md.

--conventional-graduate

lerna version --conventional-commits --conventional-graduate=package-2,package-4

  

# force all prerelease packages to be graduated

lerna version --conventional-commits --conventional-graduate

But when using this tag,lerna vesionWill upgrade the specified package (separated by commas) or use*Specify all packages. and--force-publishSimilarly, this command will work regardless of whether the current head is released or not, and any package that is not pre released will be ignored. If an unspecified package (if one is specified) or a package that is not pre published changes, the packages will be updated according to their usual usage--conventional-commitsVersion control.

“Upgrading” a package means upgrading a pre released package to a released version, such as[email protected] => [email protected]。

Note: when a package is specified, the dependencies of the specified package will be released, but will not be upgraded. Must be with--conventional-commitsUse together

--conventional-prerelease

lerna version --conventional-commits --conventional-prerelease=package-2,package-4

  

# force all changed packages to be prereleased

lerna version --conventional-commits --conventional-prerelease

When using this tag,lerna versionThe specified package will be published in a pre release version (separated by commas) or using the*Specify all packages.

--create-release <type>

lerna version --conventional-commits --create-release github

lerna version --conventional-commits --create-release gitlab

When using this flag,lerna versionAn official GitHub or gitlab version record will be created based on the changed package. Need to pass--conventional-commitsTo create changlog.

For GitHub authentication, the following environment variables need to be defined.

• GH_TOKEN (required) – Your GitHub authentication token (under Settings > Developer settings > Personal access tokens).
• GHE_API_URL – When using GitHub Enterprise, an absolute URL to the API.
• GHE_VERSION – When using GitHub Enterprise, the currently installed GHE version. Supports the following versions.

Gitlab certification, the following environment variables need to be defined.

• GL_TOKEN (required) – Your GitLab authentication token (under User Settings > Access Tokens).
• GL_API_URL – An absolute URL to the API, including the version. (Default: https://gitlab.com/api/v4)

Note: and are not allowed--no-changelogUse together

This option is also available in thelerna.jsonMedium configuration:

{

    "changelogPreset": "angular"

}

If the preset exports a builder function (e.g. conventional-changelog-conventionalcommits), you can specify the preset configuration too:

{

    "changelogPreset": {

        "name": "conventionalcommits",

        "issueUrlFormat": "{{host}}/{{owner}}/{{repository}}/issues/{{id}}"

    }

}

--exact

lerna version --exact

--force-publish

lerna version --force-publish=package-2,package-4

  

# force all packages to be versioned

lerna version --force-publish

Force update version

This operation will be skippedlerna changedCheck, even if the package does not make any changes, the version will be updated

--git-remote <name>

lerna version --git-remote upstream

Will be localcommitPush to the specified remote location. The default isorigin

--ignore-changes

Files ignored in change detection

lerna version --ignore-changes '**/*.md' '**/__tests__/**'

It is recommended that thelerna.jsonMedium configuration:

{

    "ignoreChanges": ["**/__fixtures__/**", "**/__tests__/**", "**/*.md"]

}

--no-ignore-changesDisable any existing ignore configuration:

--ignore-scripts

prohibitlifecycle scripts

--include-merged-tags

lerna version --include-merged-tags

--message <msg>

-mAlias, equivalent togit commit -m

lerna version -m "chore(release): publish %s"

# commit message = "chore(release): publish v1.0.0"

  

lerna version -m "chore(release): publish %v"

# commit message = "chore(release): publish 1.0.0"

  

# When versioning packages independently, no placeholders are replaced

lerna version -m "chore(release): publish"

# commit message = "chore(release): publish

#

# - [email protected]

# - [email protected]"

It can also be in thelerna.jsonto configure:

{

    "command": {

        "version": {

            "message": "chore(release): publish %s"

        }

    }

}

--no-changelog

lerna version --conventional-commits --no-changelog

Not generatedCHANGELOG.md。

Note: you can’t talk to me--create-releaseUse together

--no-commit-hooks

By default,lerna versionWill rungit commit hooks. Use this flag to blockgit commit hooksfunction.

--no-git-tag-version

By default,lerna versionChanges will be submitted topackage.jsonFile and label. Using this tag prevents the default behavior.

--no-granular-pathspec

By default, during version creation, thegit add -- packages/*/package.jsonOperation.

You can also change the default behavior except submitpackage.jsonThe premise is to protect sensitive data.

// leran.json

{

    "version": "independent",

    "granularPathspec": false

}

--no-private

excludeprivate:truePackage of

--no-push

By default, lerna version will push the committed and tagged changes to the configured git remote.

Pass --no-push to disable this behavior.

--preid

lerna version prerelease

# uses the next semantic prerelease version, e.g.

# 1.0.0 => 1.0.1-alpha.0

  

lerna 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

Version semantics

--sign-git-commit

npm version option

--sign-git-tag

npm version option

--force-git-tag

Replace the existingtag

--tag-version-prefix

Custom version prefix. Default tov

# locally

lerna version --tag-version-prefix=''

# on ci

lerna publish from-git --tag-version-prefix=''

--yes

lerna version --yes

# skips `Are you sure you want to publish these packages?`

Skip all prompts

Generate update logCHANGELOG.md

If you start using multi packet storage after a period of time--conventional-commitsTags, you can also use themconventional-changelog-cliandlerna execCreate a changelog for the previous version:

# Lerna does not actually use conventional-changelog-cli, so you need to install it temporarily

npm i -D conventional-changelog-cli

# Documentation: `npx conventional-changelog --help`

  

# fixed versioning (default)

# run in root, then leaves

npx conventional-changelog --preset angular --release-count 0 --outfile ./CHANGELOG.md --verbose

npx lerna exec --concurrency 1 --stream -- 'conventional-changelog --preset angular --release-count 0 --commit-path $PWD --pkg $PWD/package.json --outfile $PWD/CHANGELOG.md --verbose'

  

# independent versioning

# (no root changelog)

npx lerna exec --concurrency 1 --stream -- 'conventional-changelog --preset angular --release-count 0 --commit-path $PWD --pkg $PWD/package.json --outfile $PWD/CHANGELOG.md --verbose --lerna-package $LERNA_PACKAGE_NAME'

If you use a custom --changelog-preset, you should change --preset value accordingly in the example above.

Lifecycle Scripts

// preversion: Run BEFORE bumping the package version.

// version: Run AFTER bumping the package version, but BEFORE commit.

// postversion: Run AFTER bumping the package version, and AFTER commit.

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

1. Detect changed packages, choose version bump(s)
2. Run preversion lifecycle in root
3. For each changed package, in topological order (all dependencies before dependents):
4. Run preversion lifecycle
5. Update version in package.json
6. Run version lifecycle
7. Run version lifecycle in root
8. Add changed files to index, if enabled
9. Create commit and tag(s), if enabled
10. For each changed package, in lexical order (alphabetical according to directory structure):
11. Run postversion lifecycle
12. Run postversion lifecycle in root
13. Push commit and tag(s) to remote, if enabled
14. Create release, if enabled

lerna publish

Lerna publish #, published since the last release, depends on updated packages

Lerna publish from git # shows the packages tagged in the current submission

Lerna publish from package # displays packages whose current version of publication does not exist in the registry (previously not published to NPM)

At run time, the command does one of the following:

• Released from the last version dependent on the updated packages (behind the call)lerna version(judgment)
• This is a legacy of version 2. X
• The packages displayed are tagged in the current submission
• The displayed publication is in the latest submission. Packages whose current version does not exist in the registry (previously not published to NPM)
• Release packages that have not been versioned in previous submissions and have been deployed by canary（canary release)

Lerna cannot publish private packcage（"private":true)

During all publishing operations, appropriate lifecycle scripts are used（lifecycle scripts）Called in the root directory and in each package (unless called by--ignore-scriptsDisabled).

Positionals

• bump from-git

exceptlerna versionIn addition to the supported semver keywords,lerna publishAlso supportfrom-gitkeyword. This will identifylerna versionAnd publish them to NPM. This is very useful in CI scenarios where you want to manually increase the version but consistently publish the package content itself through an automated process

• bump from-package

Andfrom-gitKeywords are similar, except that the list of packages to be published is checked by eachpackage.jsonAnd determine whether there is no package version in the registry to determine. Any version that does not exist in the registry will be published. When the previouslerna publishThis feature is useful when all packages could not be published to the registry.

Command Options

lerna publishIn addition to the following options, we also supportlerna versionAll options for:

• --canary
• --contents <dir>
• --dist-tag <tag>
• --git-head <sha>
• --graph-type <all|dependencies>
• --ignore-scripts
• --ignore-prepublish
• --legacy-auth
• --no-git-reset
• --no-granular-pathspec
• --no-verify-access
• --otp
• --preid
• --pre-dist-tag <tag>
• --registry <url>
• --tag-version-prefix
• --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}

For the package that has been changed in the last submission, more detailed version control should be done. Similar to Canary deployment, build fault tolerance test of production environment. If it is a unified version control, other package version numbers will not be upgraded, only the changed package will be precisely debugged.

--contents <dir>

Subdirectory publishing. Subdirectories must contain package.json .

lerna publish --contents dist

# publish the "dist" subfolder of every Lerna-managed leaf package

--dist-tag <tag>

lerna publish --dist-tag custom-tag

Custom NPMRelease label. The default islatest

This option can be used to defineprereleaseperhapsbetaedition

be careful: npm install my-packageThe default installation islatestedition.

Install other versionsnpm install [email protected].

--git-head <sha>

Only withfrom-packageIn combination with the specifiedgit <sha>release

It can also be specified with an environment variable

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

--graph-type <all|dependencies>

npmBuild onpackage dependenciesThe default method isdependencies, list onlydependencies。allWill be listeddependenciesanddevDependencies

lerna publish --graph-type all

You can also pass thelerna.jsonto configure:

{

    "command": {

        "publish": {

            "graphType": "all"

        }

    }

}

--ignore-scripts

closeNPM script lifecycle eventsTrigger of

--ignore-prepublish

Near closureNPM script lifecycle prepublish eventTrigger of

--legacy-auth

Pre release authentication

lerna publish --legacy-auth aGk6bW9t

--no-git-reset

By default,lerna publishThe contents of the staging area will be submitted. Namelylerna publishThe version in the local package was changed at the time of publishing, and it was also submitted to GIT.

If the above situation is not avoided, it can be used--no-git-reset. This pair is configured as a pipe--canaryIt’s very useful to use. For example, what has changedpackage.jsonThe version number of may be used in the next operation (such as docker builds).

lerna publish --no-git-reset

--no-granular-pathspec

By default, lerna publish will attempt (if enabled) to git checkout only the leaf package manifests that are temporarily modified during the publishing process. This yields the equivalent of git checkout -- packages/*/package.json, but tailored to exactly what changed.

If you know you need different behavior, you’ll understand: Pass --no-granular-pathspec to make the git command literally git checkout -- .. By opting into this pathspec, you must have all intentionally unversioned content properly ignored.

This option makes the most sense configured in lerna.json, as you really don’t want to mess it up:

{

    "version": "independent",

    "granularPathspec": false

}

The root-level configuration is intentional, as this also covers the identically-named option in lerna version.

--no-verify-access

By defaultlernaThe permissions of the logged in user on the package to be published are verified. Using this tag will prevent the default behavior.

If you are using a third party not supportednpm access ls-packagesNPM library, which needs to be used. Or inlerna.jsonSet incommand.publish.verifyAccessbyfalse。

Use with caution

--otp

When publishing a package that requires dual authentication, you need to specifyOne time password

lerna publish --otp 123456

When onNPM dual authenticationAfter that, the second verification of account and NPM operations can be performed through configuration. NPM version greater than5.5.0

Validation tools

The valid time of password is 30s, and it needs to be reentered for verification after expiration

--preid

Unlike the lerna version option of the same name, this option only applies to --canary version calculation.

and--canaryUse it together to specify the semantic version

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 using this tag,lerna publish --canaryChange the incrementpremajor, preminor, prepatchOrprereleaseThe semantic version of.

Semantic release identifier

--pre-dist-tag <tag>

lerna publish --pre-dist-tag next

Effect and--dist-tagIt’s the same. Applies only to pre released versions of the release.

--registry <url>

--tag-version-prefix

Change label prefix

If splitlerna versionandlerna publish, you need to set it all:

# locally

lerna version --tag-version-prefix=''

# on ci

lerna publish from-git --tag-version-prefix=''

It can also be in thelerna.jsonTo configure this attribute in, the effect is equivalent to the above two commands:

{

"tagVersionPrefix": "",

"packages": ["packages/*"],

"version": "independent"

}

--temp-tag

When delivered, this flag will change the default publishing process, first publish all changed packages to a temporary dis tag (‘lerna temp ‘), and then move the new version to‘–dist-tag ‘(the default is’ latest ‘).

This is usually unnecessary because by default, lerna publishes packages in topological order (all dependencies precede dependencies)

--yes

lerna publish --canary --yes

# skips `Are you sure you want to publish the above changes?`

Skip all confirmation prompts

stayContinuous integration (CI)Very useful, automatically answer the confirmation prompt when publishing

Configuration of each package

Each package can be changed bypublishConfigTo change some of the behavior at the time of release.

publishConfig.access

When publishing ascopePackage (e.g,@mycompany/rocks）You must set theaccess：

"publishConfig": {

    "access": "public"

}

• If you use this property in a package that does not use scope, it will fail
• If you want to keep a scope package private (i.e,"restricted"）Then you don’t need to set it

Note that this is the same as setting in the package"private":trueNot the same; if it is setprivateField, the package will not be published under any circumstances.

publishConfig.registry

"publishConfig": {

    "registry": "http://my-awesome-registry.com/"

}

• You can also pass the--registryOr in lerna.json Set incommand.publish.registryGlobal control

publishConfig.tag

Customize the label of the package when it is publishedtag:

"publishConfig": {

    "tag": "flippin-sweet"

}

• --dist-tagThe values in each package are overridden
• This value is ignored when [– Canary] is used

publishConfig.directory

Non standard fields, custom published files

"publishConfig": {

    "directory": "dist"

}

NPM script life cycle

// 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 publishWhen executing, call in the following orderNPM script life cycle：

1. If implicit version management is used, allversion lifecycle scripts。
2. Run prepublish lifecycle in root, if enabled
3. Run prepare lifecycle in root
4. Run prepublishOnly lifecycle in root
5. Run prepack lifecycle in root
6. For each changed package, in topological order (all dependencies before dependents):
7. Run prepublish lifecycle, if enabled
8. Run prepare lifecycle
9. Run prepublishOnly lifecycle
10. Run prepack lifecycle
11. Create package tarball in temp directory via JS API
12. Run postpack lifecycle
13. Run postpack lifecycle in root
14. For each changed package, in topological order (all dependencies before dependents):
15. Publish package to configured registry via JS API
16. Run publish lifecycle
17. Run postpublish lifecycle
18. Run publish lifecycle in root

• To avoid recursive calls, don’t use this root lifecycle to run lerna publish

1. Run postpublish lifecycle in root
2. Update temporary dist-tag to latest, if enabled

Filtering options

• --scopeInstall dependency [string] for matched package
• --ignoreOpposite [string]
• --no-privateExcluding private packcage
• --sinceContains packages changed from the specified [ref] dependency. If there is no [ref], the default is the latest tag
• --exclude-dependentsWhen – since is used to run the command, all pass through dependencies are excluded and the default “changed” algorithm [Boolean] is overridden
• --include-dependentsStart command contains all passed dependencies, ignoring — scope, – ignore, or — since [Boolean]
• --include-dependenciesStart command contains all passed dependencies, ignoring — scope, – ignore, or — since [Boolean]
• --include-merged-tagsContains the tag [Boolean] from the merge branch when running the command with – since

Global options

• --loglevelPrint log level [string] default: Info
• --concurrencyNumber of processes started during parallel tasks [number] [default: 4]
• --reject-cyclesIf packages depend on each other, fail [Boolean]
• --no-progressClose progress bar [Boolean]
• --no-sortNot following topological ordering [Boolean]
• --max-bufferSet the buffer (in bytes) for the execution of the subcommand [number]
• -h, --help display help information
• -v, --versiondisplay version information

Concept

lerna.json

{

    "Version": "1.1.3", // version

    "Npmclient": "NPM", // NPM client

    "command": {

        "publish": {

            "Ignorechanges": ["ignored file", "*. MD"], // files ignored in publishing detection

            "Message": "chord (release): publish" // the version information of the tag when publishing

            "registry": " https://npm.pkg.github.com "// source

    },

    "bootstrap": {

        "Ignore": "component - *" // files ignored in bootstrap

        "Npmclientargs": ["-- no package lock"], // command line parameters

    },

    "version": {

        "Allowbranch": [// branches allowed to run lerna version

                "master",

                "feature/*"

        ],

    "Message": "chord (release): publish% s" // the version information of the tag when creating a version

    }

},

    "ignoreChanges": [

        "**/__fixtures__/**",

        "**/__tests__/**",

        "**/*.md"

    ],

    "Packages": ["packages / *"], // package location

}

Wizard

Here is a novice guide toollerna-wizard