By: adminPosted on

複数のパッケージを持つJavaScriptプロジェクトを管理するためのツール。

  • について
  • はじめに
  • どのように動作しますか
  • トラブルシューティング
  • コマンド
  • その他
  • Lerna。json
  • Flags

について大きなコードベースを独立したバージョン管理パッケージに分割することは、コード共有に非常に便利です。 しかし、多くのリポジトリ間で変更を行うことは面倒で追跡するのが難しく、リポジトリ間でのテストは非常に複雑になります。

これらの（および他の多くの）問題を解決するために、いくつかのプロジェクトはコードベースをマルチパッケージリポジトリ（時にはmonoreposと呼ばれる）に整理します。 Babel、React、Angular、Ember、Meteor、Jestなどのプロジェクトは、すべてのパッケージを単一のリポジトリ内で開発します。

lernaは、gitとnpmでマルチパッケージリポジトリを管理するワークフローを最適化するツールです。

Lernaはまた、開発環境およびビルド環境でのパッケージの多数のコピーの時間とスペースの要件を減らすことができます-通常、プロジェクトを多くの別々のNPMパ 詳細については、ホイストのドキュメントを参照してください。

Lerna repoはどのように見えますか？

実際にはそれにはほとんどありません。 次のようなファイルシステムがあります:

my-lerna-repo/ package.json packages/ package-1/ package.json package-2/ package.json

Lernaは何ができますか？

Lernaの2つの主要なコマンドはlerna bootstrapとlerna publishです。

bootstrapはリポジトリ内の依存関係をリンクします。 publishは、更新されたパッケージを公開するのに役立ちます。

はじめに

以下の手順はLerna2のためのものです。x.1の代わりに使用することをお勧めします。新しいLernaプロジェクトのためのx。 1を参照する必要がある場合は、wikiを確認してください。xのREADME。

まず、npmを使ってlernaをグローバルにインストールしましょう。

$ npm install --global lerna

次に、新しいgitリポジトリを作成します:

$ git init lerna-repo$ cd lerna-repo

そして今のは、Lernaレポにそれを回してみましょう:

$ lerna init

リポジトリは次のようになります:

lerna-repo/ packages/ package.json lerna.json

これにより、lerna.json設定ファイルとpackagesフォルダが作成されます。

仕組み

Lernaでは、固定または独立のいずれかのモードを使用してプロジェクトを管理できます。

固定/ロックモード(デフォルト)

固定モードLernaプロジェクトは単一のバージョンラインで動作します。 バージョンは、プロジェクトのルートにあるlerna.jsonファイルのversionキーの下に保持されます。 lerna publishを実行したときに、最後にリリースが行われたときからモジュールが更新されている場合、リリースしている新しいバージョンに更新されます。 これは、必要なときにのみパッケージの新しいバージョンを公開することを意味します。

これはバベルが現在使用しているモードです。 すべてのパッケージバージョンを自動的に結び付ける場合は、これを使用します。 このアプローチの1つの問題は、いずれかのパッケージを大きく変更すると、すべてのパッケージが新しいメジャーバージョンを持つことになります。

独立モード(–independent)

独立モードLernaプロジェクトでは、メンテナは互いに独立してパッケージバージョンをインクリメントできます。 公開するたびに、変更されたパッケージごとにプロンプトが表示され、パッチ、マイナー、メジャー、またはカスタムの変更かどうかを指定します。

独立モードでは、各パッケージのバージョンをより具体的に更新することができ、コンポーネントのグループに対して理にかなっています。 このモードをsemantic-releaseのようなものと組み合わせると、痛みが少なくなります。 （これに関する作業はすでにatlassian/lerna-semantic-releaseで行われています）。

lerna.jsonのversionキーは独立モードでは無視されます。

トラブルシューティング

Lernaの使用中に問題が発生した場合は、問題の答えを見つける可能性のあるトラブルシューティング文書を確認してくださ

よくある質問

を参照してくださいFAQ.md.

コマンド

init

$ lerna init

新しいLernaレポを作成するか、既存のレポを現在のバージョンのLernaにアップグレードします。

lernaは、レポがすでにgit initで初期化されていると仮定します。

実行すると、このコマンドは:

  1. まだ存在しない場合は、lernaをdevDependencyとしてpackage.json追加します。
  2. lerna.json設定ファイルを作成して、version番号を格納します。

新しいgitリポジトリの出力例:

$ lerna initlerna info version v2.0.0lerna info Updating package.jsonlerna info Creating lerna.jsonlerna success Initialized Lerna files

–independent,-i

$ lerna init --independent

このフラグは、独立したバージョニングモードを使用するようにLernaに指示します。

–exact

$ lerna init --exact

デフォルトでは、lerna initはnpm install --save-dev lernaと同様に、lernaのローカルバージョンを追加または更新するときにキャレット範囲を使用します。

lernaを保持するには1.”正確な”比較のx動作は、このフラグを渡します。 それ以降のすべての実行に対して完全一致を強制するようにlerna.jsonを設定します。

{ "lerna": "2.0.0", "command": { "init": { "exact": true } }, "version": "0.0.0"}

bootstrap

$ lerna bootstrap

現在のLernaリポジトリ内のパッケージをブートストラップします。 すべての依存関係をインストールし、相互依存関係をリンクします。

実行すると、このコマンドは:

  1. npm install 各パッケージのすべての外部依存関係。
  2. お互いの依存関係であるすべてのLernapackagesを一緒にシンボリックリンクします。
  3. npm prepublishすべてのブートストラップパッケージ。

lerna bootstrap --ignore、--scope、--include-filtered-dependenciesフラグを尊重します(Flagsを参照)。

後に配置してnpmクライアントに余分な引数を渡します--:

$ lerna bootstrap -- --production --no-optional

で設定することもできます。lerna.json:

{ ... "npmClient": "yarn", "npmClientArgs": }

どのようにbootstrap作品

のは、例としてbabelを使用してみましょう。

  • babel-generator そしてsource-map（他の中でも）はbabel-coreの依存関係です。
  • babel-core‘spackage.jsonは、以下に示すように、これらのパッケージの両方をdependenciesのキーとして一覧表示します。
// babel-core package.json{ "name": "babel-core", ... "dependencies": { ... "babel-generator": "^6.9.0", ... "source-map": "^0.5.0" }}
  • Lernaは、各依存関係がLernaレポの一部でもあるかどうかをチェックします。
    • この例では、babel-generatorは内部依存関係にすることができますが、source-mapは常に外部依存関係になります。
    • babel-generatorのpackage.jsonのbabel-coreのバージョンはpackages/babel-generatorによって満たされ、内部依存関係に渡されます。
    • source-mapは通常のようにnpm installed（またはyarned）です。
  • packages/babel-core/node_modules/babel-generator packages/babel-generator
  • へのシンボリックリンクこれにより、ネストされたディレクトリのインポートが可能になります

:

  • パッケージ内の依存関係バージョンがレポ内の同じ名前のパッケージによって満たされない場合、通常のようにnpm installed（またはyarned）になります。
  • Dist-タグは、latestのように、semverの範囲を満たしません。
  • 循環依存関係は、エディタ/IDEに影響を与える可能性のある循環シンボリックリンクになります。

Webstormは、循環シンボリックリンクが存在するときにロックされます。 これを防ぐには、Preferences | Editor | File Types | Ignored files and foldersの無視されるファイルとフォルダーのリストにnode_modulesを追加します。

publish

$ lerna publish

現在のLernaプロジェクトのパッケージをPublishします。

は、更新されたパッケージの新しいリリースを作成します。 新しいバージョンの入力を求められます。 Npmへの公開プロセスで新しいgit commit/タグを作成します。

より具体的には、このコマンドは:

  1. これに相当するlerna updatedを実行して、どのパッケージを公開する必要があるかを判断します。
  2. 必要に応じて、versionキーをlerna.jsonにインクリメントします。
  3. 更新されたすべてのパッケージのpackage.jsonを新しいバージョンに更新します。
  4. 更新されたパッケージのすべての依存関係を、キャレット(^)で指定された新しいバージョンで更新します。
  5. 新しいバージョンの新しいgit commitとタグを作成します。
  6. 更新されたパッケージをnpmに公開します。

lernaはプライベートとしてマークされているパッケージを公開しません("private": trueのpackage.json)。

–exact

$ lerna publish --exact

このフラグを指定して実行すると、publishはsemver互換（^）ではなく、更新されたパッケージ内の更新された依存関係を正確に（句読点なしで）指定します。

詳細については、パッケージを参照してください。json依存関係のドキュメント。このフラグを指定して実行すると、publishは指定されたnpm dist-tag（デフォルトはlatest）を使用してnpmに公開されます。

このオプションは、prereleaseまたはbetaバージョンを公開するために使用できます。

注: latestタグは、ユーザーがnpm install my-packageを実行するときに使用されるタグです。 別のタグをインストールするには、npm install [email protected]を実行します。

–canary,-c

$ lerna publish --canary$ lerna publish --canary=beta

このフラグを指定して実行すると、publishはより詳細な方法で(コミットごとに)パッケージを発行します。 Npmに公開する前に、現在のversionを取得し、次のマイナーバージョンにバンプし、提供されたメタ接尾辞（デフォルトはalpha）を追加し、現在のgit shaを追加することで、新しいversionタグを作成します（例：1.0.0は1.1.0-alpha.81e3b443になります）。

このフラグの使用目的は、コミットレベルごとのリリースまたは夜間のリリースです。

–conventional-commits

$ lerna publish --conventional-commits

このフラグで実行すると、publishは従来のCommits仕様を使用してバージョンバンプを決定し、CHANGELOGを生成します

–git-remote

$ lerna publish --git-remote upstream

このフラグで実行すると、publishはgitの変更をoriginではなく指定されたリモートにプッシュします。

–skip-git

$ lerna publish --skip-git

このフラグを指定して実行すると、publishはgitコマンドを実行せずにnpmに公開されます。

はnpmにのみ公開します。gitの変更のコミット、タグ付け、プッシュをスキップします（これは公開にのみ影響します）。

–skip-npm

$ lerna publish --skip-npm

このフラグで実行すると、publishはすべてのpackage.jsonパッケージバージョンと依存関係バージョンを更新しますが、実際にはパッケージをnpmに公開しません。

これは、その後修正されたnpmの問題の回避策として便利でした。 READMEの変更を使用して公開する場合は、--skip-npmを使用し、パッケージごとに最後のnpm publishを手動で実行します。

このフラグを--skip-gitと組み合わせることで、コミット、タグ付け、プッシュ、公開することなく、バージョンと依存関係を更新することができます。

バージョンと依存関係のみを更新し、実際には公開しません（これは公開にのみ影響します）。

–force-publish

$ lerna publish --force-publish=package-2,package-4# force publish all packages$ lerna publish --force-publish=*

このフラグを指定して実行すると、publishは指定されたパッケージ(カンマ区切り)または*を使用してすべてのパッケージを強制的に発行します。

これにより、変更されたパッケージのlerna updatedチェックがスキップされ、git diff変更されていないパッケージが強制的に更新されます。

–はい

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

このフラグを指定して実行すると、publishはすべての確認プロンプトをスキップします。 継続的統合(CI)で、公開確認プロンプトに自動的に応答するのに役立ちます。

–cd-version

このフラグを指定して実行すると、publishはバージョン選択プロンプトをスキップし(独立モードで)、次の指定されたセマンティックバージョンを使用します。 すべてのプロンプトを回避するには、--yesフラグを使用する必要があります。 これは、ビルドシステムがコマンドプロンプトなしで公開する必要がある場合に便利です。 通常モードと独立モードの両方で動作します。

–pre-id

–repo-version

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

このフラグを指定して実行すると、publishはバージョン選択プロンプトをスキップし、指定されたバージョンを使用します。 公開するバージョンが既にわかっている場合に、ユーザー入力プロンプトをバイパスするのに便利です。

–message,-m

このフラグを指定して実行すると、publishは発行のためにバージョン更新をコミットするときに指定されたメッセージを使用します。 Commitizenやsemantic-releaseを使用するプロジェクトなど、コミットメッセージが特定のガイドラインに従うことを期待するプロジェクトにlernaを統合するのに便利です。

メッセージに%sが含まれている場合、新しいグローバルバージョンのバージョン番号に接頭辞”v”が付いたものに置き換えられます。 これは、--independentを使用するときに”グローバル”バージョンがないため、デフォルトの”固定”バージョン管理モードを使用する場合にのみ適用されることに注意してくださ

更新

$ lerna updated

最後のリリース（最後のgitタグ）以降に変更されたpackagesを確認します。

Lernaは最後に作成されたgitタグを決定し、git diff --name-only v6.8.1を実行して、そのタグ以降に変更されたすべてのファイルを取得します。 次に、更新されたファイルを持つパッケージの配列を返します。

publishコマンドの設定はupdatedコマンドにも影響することに注意してください。 例えばconfig.publish.ignore

–json

$ lerna updated --json

このフラグを指定して実行すると、updatedは次の形式のオブジェクトの配列を返します:

クリーン

$ lerna clean

すべてのパッケージからnode_modulesディレクトリを削除します。

lerna cleanは--ignore、--scope、および--yesフラグを尊重します（フラグを参照）。

diff

$ lerna diff $ lerna diff# diff a specific package$ lerna diff package-name

最後のリリース以降のすべてのパッケージまたは単一のパッケージをDiffします。

はlerna updatedに似ています。 このコマンドはgit diffを実行します。

ls

$ lerna ls

現在のLernaリポジトリ内のすべての公開パッケージを一覧表示します。

lerna lsは--ignoreおよび--scopeフラグを尊重します（フラグを参照）。

–json

$ lerna ls --json

このフラグを指定して実行すると、lsは次の形式のオブジェクトの配列を返します:

run

そのスクリプトを含む各パッケージでnpmスクリプトを実行します。 スクリプトの実行に破線の引数を渡すには、ダブルダッシュ(--)が必要です。

lerna run--concurrency, --scope, --ignore, --stream, および--parallelフラグ(フラグを参照)。

$ lerna run --scope my-component test

注:--parallelフラグを使用する場合は、このコマンドのスコープ(および以下のlerna exec)を制限することをお勧めします。 Ymmv

exec

$ lerna exec -- <command> # runs the command in all packages$ lerna exec -- rm -rf ./node_modules$ lerna exec -- protractor conf.js

各パッケージで任意のコマンドを実行します。 スポーンされたコマンドに破線のフラグを渡すにはダブルダッシュ(--)が必要ですが、すべての引数が位置指定されている場合は必要ありません。

lerna exec--concurrency, --scope, --ignore, および--parallelフラグ(フラグを参照)。

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

実行時間の長いプロセスを生成するには、--parallelフラグを渡します:

# transpile all modules as they change in every package$ lerna exec --parallel -- babel src -d lib -w

また、環境変数を使用して現在のパッケージの名前を取得することもできますLERNA_PACKAGE_NAME:

$ lerna exec -- npm view $LERNA_PACKAGE_NAME

また、環境変数を介して複雑なdir構造体で、ルートdirにあるスクリプトを実行することもできますLERNA_ROOT_PATH:

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

ヒント:コマンドは、指定された同時実行を使用して並列に生成されます(--parallelを除く)。 出力はパイプ処理されるため、確定的ではありません。 コマンドを1つのパッケージで次々に実行したい場合は、次のように使用します:

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

–bail

$ lerna exec --bail=<boolean> <command>

このフラグは、生成されたサブプロセスのいずれかによってスローされたエラーが発生したときにexecコマンドが実行を停止するかどうかを示します。 デフォルト値はtrueです。

import

$ lerna import <path-to-external-repository>

コミット履歴を持つ<path-to-external-repository>のパッケージをpackages/<directory-name>にインポートします。 元のコミットの作成者、日付、メッセージは保存されます。 コミットは現在のブランチに適用されます。

これは、既存のスタンドアロンパッケージをLernaリポジトリに集めるのに便利です。 各コミットは、パッケージディレクトリに対する相対的な変更を行うように変更されます。 そのため、たとえば、package.jsonを追加したコミットでは、代わりにpackages/<directory-name>/package.jsonが追加されます。

Misc

Lernaは、コマンドの実行中にエラーが発生したときにlerna-debug.logファイル(npm-debug.logと同じ)にログを記録します。

Lernaはスコープ付きパッケージもサポートしています。

引数なしでlernaを実行すると、すべてのコマンド/オプションが表示されます。

json

{ "lerna": "2.0.0", "version": "1.1.3", "commands": { "publish": { "ignore": }, "bootstrap": { "ignore": "component-*" } }, "packages": }
  • lerna: 使用されているLernaの現在のバージョン。
  • version: リポジトリの現在のバージョン。
  • commands.publish.ignore: lerna updated/publishに含まれないglobsの配列。 これは、README.mdタイプミスの修正など、変更のために不必要に新しいバージョンを公開するのを防ぐために使用します。
  • commands.bootstrap.ignore: lerna bootstrapコマンドの実行時にブートストラップされないglobsの配列。
  • commands.bootstrap.scope: lerna bootstrapコマンドの実行時にブートストラップされるパッケージを制限するglobsの配列。
  • packages: パッケージの場所として使用するglobsの配列。

Common devDependencies

ほとんどのdevDependenciesはLernaレポのルートにプルアップできます。

これにはいくつかの利点があります:

  • すべてのパッケージは、指定された依存関係の同じバージョンを使用します
  • GreenKeeperのような自動ツールを使用して、ルートの依存関係を最新の状態に保つことができます
  • 依存関係のインストール時間が短縮されます
  • より少ないストレージが必要です

devDependenciesは、”バイナリ”実行可能ファイルを提供することに注意してください。npmスクリプトで使用されるスクリプトは、使用される各パッケージに直接インストールする必要があります。

たとえば、この場合、lerna run nsp（およびパッケージのディレクトリ内のnpm run nsp）が正しく動作するためには、nsp依存関係が必要です:

{ "scripts": { "nsp": "nsp" }, "devDependencies": { "nsp": "^2.3.3" }}

Lernaへのフラグ

オプションは、設定(lerna.json)またはコマンドラインから取得できます。 さらに、configのオプションは最上位レベルに存在するか、特定のコマンドに適用される可能性があります。

:

{ "lerna": "x.x.x", "version": "1.2.0", "exampleOption": "foo", "command": { "init": { "exampleOption": "bar", } },}

この場合、exampleOptionはinitを除くすべてのコマンドで”foo”になり、ここでは”bar”になります。 いずれの場合も、コマンドラインで--example-option=bazを使用して”baz”に上書きすることができます。

–concurrency

Lernaがタスクを並列化するときに使用するスレッドの数(デフォルトは4)

$ lerna publish --concurrency 1

–scope

は、コマンドをパッケージのサブセットにスコープします。

$ lerna exec --scope my-component -- ls -la
$ lerna run --scope toolbar-* test

—

以降、スクリプトまたはコマンドを実行するときは、指定されたref以降に更新されたパッケージに操作のスコープを設定します。 refが指定されていない場合は、デフォルトで最新のタグが使用されます。

最新のタグ以降に変更されたパッケージの内容を一覧表示します:

$ lerna exec --since -- ls -la

master以降に変更されたすべてのパッケージのテストを実行します:

$ lerna run test --since master

以降に変更されたすべてのパッケージを一覧表示しますsome-branch:

$ lerna ls --since some-branch

これは、refから--sinceオプションとして使用できるため、PRが入るターゲットブランチを取得できる場合、CIで使用するときに特に便利です。 これは、機能ブランチだけでなく、マスターに入るPRsにも適しています。

–ignore

は、コマンド実行時にパッケージのサブセットを除外します。

$ lerna bootstrap --ignore component-*

ignoreフラグは、bootstrapコマンドと共に使用すると、lerna.jsonでcommands.bootstrapキーの下に設定することもできます。 コマンドラインフラグは、このオプションよりも優先されます。

{ "lerna": "2.0.0", "version": "0.0.0", "commands": { "bootstrap": { "ignore": "component-*" } }}

ヒント:globは、パッケージが存在するディレクトリ名ではなく、package.jsonで定義されたパッケージ名と照合されます。

–include-filtered-dependencies

注:これは--scopeおよび--ignoreフラグを上書きします。

つまり、--ignoreフラグに一致するパッケージがブートストラップされている別のパッケージに依存している場合、ブートストラップされます。

これは、設定されている他のパッケージに依存する単一のパッケージを”設定”したい場合に便利です。

$ lerna bootstrap --scope my-component --include-filtered-dependencies# my-component and all of its dependencies will be bootstrapped

–loglevel

レポートするログのレベル。 失敗すると、すべてのログがlerna-debugに書き込まれます。現在の作業ディレクトリにログインします。

設定よりも高いレベルのログが表示されます。 デフォルトは”info”です。

–max-buffer

基になる各プロセス呼び出しの最大バッファ長を設定します。 たとえば、lerna importの実行中に、より多くのコミットを持つリポジトリをインポートしたい場合に便利です。 その場合、組み込みバッファの長さは十分ではない可能性があります。

–no-sort

デフォルトでは、すべてのタスクは、問題のパッケージの依存関係を尊重するために、トポロジカルにソートされた順序でパッケージに実行されます。 サイクルは、lerna呼び出し全体で一貫性が保証されていない方法で、ベストエフォートベースで壊れています。

トポロジカルソートは、依存関係の多いパッケージの数が少ない場合や、一部のパッケージの実行に不釣り合いに長い時間がかかる場合に、同時実行のボ --no-sortオプションは並べ替えを無効にし、代わりに最大の同時実行性を持つ任意の順序でタスクを実行します。

このオプションは、複数の”watch”コマンドを実行する場合にも役立ちます。 lerna runはトポロジカルにソートされた順序でコマンドを実行するので、移動する前にコマンドを待ってしまう可能性があります。 これにより、”watch”コマンドを実行すると、通常は終了しないため、実行がブロックされます。 “Watch”コマンドの例は、--watchCLIフラグを指定してbabelを実行しています。

–hoist

repoルートにglobに一致する外部依存関係をインストールして、すべてのパッケージで利用できるようにします。 これらの依存関係のバイナリは依存パッケージnode_modules/.bin/ディレクトリにリンクされるため、npmスクリプトで使用できます。 オプションが存在するがglobが指定されていない場合、デフォルトは**です(すべてをホイストします)。 このオプションはbootstrapコマンドにのみ影響します。

$ lerna bootstrap --hoist

--hoistの背景については、ホイストのドキュメントを参照してください。

注意:パッケージが異なるバージョンの外部依存関係に依存している場合、最も一般的に使用されるバージョンがホストされ、警告が出力されます。

–nohoist

レポルートにglobに一致する外部依存関係をインストールしないでください。 これは、特定の依存関係の巻き上げをオプトアウトするために使用できます。

$ lerna bootstrap --hoist --nohoist=babel-*

–npm-client

installを使用して外部依存関係をインストールします。 Npm依存関係をインストールする方法を知っている実行可能ファイルである必要があります。

$ lerna bootstrap --npm-client=yarn

lerna.json:

{ ... "npmClient": "yarn"}

–use-workspaces

はYarn Workspacesとの統合を可能にします(以降で利用可能)。[email protected]+）。
配列内の値は、LernaがYarnに操作を委任するコマンドです（現在はブートストラップのみ）。
--use-workspacesがtrueの場合、packagesはpackage.json/workspaces.
の値によって上書きされます。lerna.json:

{ ... "npmClient": "yarn", "useWorkspaces": true}

–stream

子プロセスからのストリーム出力をすぐに、元のパッケージ名の前に付けます。 これにより、異なるパッケージからの出力をインターリーブできます。

$ lerna run watch --stream

–parallel

は--streamと似ていますが、同時実行とトポロジカルソートを完全に無視し、接頭辞付きのストリーミング出力を持つ一致するすべてのパッケージで、指定されたコ これは、babel src -d lib -wなどの長時間実行されるプロセスが多くのパッケージで実行される場合に推奨されるフラグです。

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

–registry

このフラグを指定して実行すると、転送されたnpmコマンドはパッケージに指定されたレジストリを使用します。

これは、すべてのパッケージでレジストリ設定を明示的に設定したくない場合に便利です。プライベートレジストリを使用する場合など、個別にjsonファイル。

–temp-tag

が渡されると、このフラグは、最初に変更されたすべてのパッケージを一時的なdist-tag(lerna-temp)にパブリッシュし、新しいバージョンをデフォルトのdist-tag(latest)に移動することにより、デフォルトのパブリッシュプロセスを変更します。

Lernaはデフォルトでパッケージをトポロジカルな順序で(依存関係の前にすべての依存関係を)公開するので、これは一般的に必要ではありません。

Wizard

cliのガイダンス（lernaの使用を開始したり、新しいチームに導入しようとしている場合）を好む場合は、lerna-wizardを好むかもしれません。 これは、明確に定義された一連の手順をご案内します:

現在のタグ

コメントを残す

メールアドレスが公開されることはありません。