- Yarnは2段階のモデルを採用しています。グローバルなCLIに加え、一貫した動作を実現するためにプロジェクトごとに固定されたバージョンも用意されています。
- yarn.lock を使用した決定論的なインストールと積極的なキャッシュにより、高速で再現性の高い依存関係管理が実現します。
- 最新のYarn Berryでは、柔軟なリンク、キャッシュ、エディタ/CI統合のために、PnP、ワークスペース、および.yarnrc.ymlが追加されています。
- 一般的なインストール時の問題を回避するには、適切なPATH設定、ロックファイルの処理、およびキャッシュ管理が不可欠です。
JavaScriptプロジェクトにYarnをインストールしようとしていて、選択肢が多すぎて少し戸惑っているなら、それはあなただけではありません。 Yarnは近年大きく進化しており、npmと共存しています。また、オペレーティングシステムや使用するプロジェクトスタイル（モノレポ、PnP、従来のnode_modulesなど）に応じて、さまざまなバージョンやインストール手順が存在します。
良いニュースは、Yarnのインストール方法と、その2層構造モデル（グローバルCLI + プロジェクト固有のYarn）の仕組みを理解すれば、すべてが腑に落ちるようになるということです。 このガイドでは、最も一般的なシステムにYarnをインストールする方法、実際のJavaScriptプロジェクトにYarnを組み込む方法、npmとの違い、そしてYarnを初めて使用する際によく発生する典型的な問題のトラブルシューティング方法について、詳しく解説します。
Yarnとは何か、そしてJavaScriptプロジェクトにとってなぜ今も重要なのか
Yarnは、Node.js用のパッケージマネージャーであり、スピード、セキュリティ、そして確実なインストールという3つの大きな目標を念頭に置いて設計されています。 Yarnは、npmがパフォーマンスや信頼性に問題を抱えていた時代に、npmの代替として誕生しました。その後npmは大幅に改善されましたが、Yarnは特にReactや最新のフロントエンドスタックを中心に、依然として非常に人気があります。
Yarn の重要な強みの 1 つは、 yarn.lock ファイルにソフトウェアを指定する必要があります。 このファイルは、すべての直接的および推移的な依存関係の正確なバージョンを修正するため、異なるマシンや CI サーバーにインストールしても常に同じ依存関係ツリーが生成され、「私のラップトップでしか動作しない」という典型的な問題が解消されます。
もう一つの特徴は、Yarnが既にダウンロードしたパッケージを再利用できる、積極的なキャッシュ動作です。 このおかげで、繰り返しインストールする作業が劇的に高速化され、必要なパッケージがすべて事前にキャッシュされていれば、Yarnはオフラインモードでも動作させることができます。
最新のYarn（バージョン2.x、3.x、4.xでは「Berry」と呼ばれることが多い）では、プラグアンドプレイ（PnP）やワークスペースなどの高度な機能が追加されています。 PnPは従来の node_modules フォルダをマニフェストファイルに置き換えることで、Node.js に各パッケージの場所を正確に伝え、ディスク容量を大幅に節約し、一部の操作を高速化します。一方、ワークスペースはモノレポに最適で、共有ロックファイルと中央集約型の依存関係管理を使用して、単一のリポジトリに複数のパッケージをリンクします。
セキュリティの観点から、Yarnは各パッケージを実行する前にチェックサムを検証します。 この整合性検証は、破損または改ざんされたアーティファクトに対する保護層をさらに強化するものであり、企業環境や機密性の高い環境において特に有用です。
Yarn ClassicとYarn Berry（モダンヤーン）の違いを理解する
インストールについて説明する前に、YarnにはClassic（1.x）とBerry（2.x/3.x/4.x）という2つの大きなファミリーがあることを理解しておくことが重要です。 Yarn Classic は独自の履歴リポジトリに存在し、セキュリティ修正のみを受け取ります。一方、すべてのアクティブな開発は、より新しい Berry ラインに集中しています。 yarnpkg/berry レポ。
Yarn Classic (バージョン 1.22 付近) は、グローバル版をインストールした際にほとんどの人が今でも入手しているものです。 yarn npm を使用した CLI。 現在、そのグローバルCLIは主にランチャーとして機能します。Berryで構成されたプロジェクト内では、グローバルコマンドは実行をローカルのプロジェクト固有のYarnバージョンに委任するだけであり、グローバルツールに手を加えることなくプロジェクトのツールチェーンをアップグレードできます。
Yarn Berryは、特にPlug'n'Playと強力なプラグインシステムなど、大幅なアーキテクチャ変更を導入しています。 デフォルトでは、ベリーはPnPを優先します。 node_modulesは、ゼロインストールワークフロー（リポジトリにコミットされた依存関係）をサポートし、きめ細かな設定を可能にします。 .yarnrc.ymlこれには、モジュールのリンク方法、キャッシュの管理方法、レジストリやプロキシの定義方法などが含まれます。
Yarnの開発者自身も、可能な限り1.xから最新のBerryリリースへの移行を強く推奨しています。 最新のリリースはより長期間積極的にメンテナンスされており、Classic に存在する問題の全クラスを修正し、構成の柔軟性を提供します。 nodeLinker クラシック設定を引き続き使用できるように node_modules PnPが適さない場合は、レイアウトまたはpnpmスタイルのシンボリックリンクを使用します。
もしあなたのエコシステムやツールがまだPnPに対応していないとしても、行き詰まる必要はありません。 単に設定するだけで nodeLinker: node-modules in .yarnrc.ymlBerryは、従来のnpmインストールに近い動作をしながら、決定論的なロックファイル、キャッシュ動作、および改善されたCLIエクスペリエンスを維持しています。
システム要件とグローバルな糸設置戦略
オペレーティングシステムの種類に関わらず、Yarnの真の必須要件はNode.jsがインストールされていることです。 YarnはNodeベースのCLIであり、実行にはNodeが必要なので、まずNodeが利用可能であることを簡単なコマンドで確認してください。 node -v ターミナルで実行してください。「コマンドが見つかりません」というエラーではなく、バージョン番号が表示されれば、問題ありません。
Node.jsがインストールされていない、またはバージョンが古い場合は、お使いのプラットフォームに推奨されている方法でインストールまたはアップグレードしてください。 LinuxではディストリビューションパッケージやNodeSourceリポジトリ、macOSではHomebrew、MacPorts、nvm、Windowsでは公式インストーラーやChocolatey、Scoopなどのパッケージマネージャーが利用できます。多くのYarnワークフローは少なくともNode 14.18を前提としており、Berryの場合はNode 16または18 LTSが最適なバージョンとなることが多いです。
Yarnの著者らは、2段階の設置モデルを推奨している。 まず、グローバルをインストールします yarn CLIで一度（通常はnpm経由で）設定を行い、その後、各プロジェクト内でそのグローバルコマンドを使用して、リポジトリ内に存在するプロジェクト固有のYarnバージョンを設定します。これにより、すべての貢献者とCIジョブが、プロジェクトで定義されたまったく同じYarnバージョンを実行することが保証されます。
npm を介してグローバルな Yarn CLI をインストールするのは簡単です。 npmはNode.jsにデフォルトで同梱されているため、以下のコマンドを実行できます。
sudo npm install -g yarn
インストールが完了したら、グローバルCLIにアクセスできることを確認してください。 実行：
yarn --version
次のようなものを見たら 1.22.xつまり、グローバル版のクラシックランチャーが正常に動作しているということです。 今後、Berryを使用するプロジェクトにアクセスすると、このグローバルコマンドによって、リポジトリに保存されているローカルで設定されたYarnリリースに制御が透過的に渡されます。
特定のJavaScriptプロジェクトにYarnをインストールする
グローバルCLIの準備が整ったので、次のステップは各プロジェクトに特定のYarnバージョンを「固定」することです。 これはまさに、チームメンバーのマシンやCI/CDパイプライン全体で一貫性を確保するものです。全員が同じYarnバイナリを実行するため、同じ動作を共有します。
まず、プロジェクトのディレクトリに移動してください（新規アプリを作成する場合は、新しいディレクトリを作成してください）。 具体的な例を挙げますと、以下の通りです。
mkdir my-project
cd my-project
そのフォルダ内で特別な yarn set version 最新のBerryリリースを選択するコマンド。 典型的な選択肢としては、積極的に開発されている「ベリー」系統を追跡することが挙げられる。
yarn set version berry
舞台裏では、Yarn は「berry」を最新の Berry バイナリに解決し、それをダウンロードして、 .yarn/releases プロジェクト内のディレクトリ。 同時に、 .yarnrc.yml プロジェクトルートにあるファイルで、グローバルランチャーにそのローカルバイナリに処理を委譲するように指示します。
あなたが今実行する場合 yarn --version プロジェクト内部から再度操作すると、出力はプロジェクトで固定されたバージョンに変更されます。 次のようなものが表示されるかもしれません。 4.5.0 または別の 3.x/4.x リリース。これは、グローバルな Classic CLI ではなく、リポジトリでホストされているローカルの Berry CLI を使用していることを示します。
この時点から、そのディレクトリ（またはそのサブディレクトリ）で実行されるすべてのYarnコマンドは、プロジェクト固有のYarnバージョンを使用するようになります。 これにより、チームは開発者マシンに単一のグローバルランチャーをインストールしたまま、さまざまなプロジェクトをそれぞれのペースで新しいYarnリリースに段階的に移行することができます。
日常的な開発のための基本的なYarnコマンド
Yarnをインストールしてプロジェクトに組み込めば、ほとんどの日常業務をこなすのに必要なコマンドはごくわずかです。 CLIは多機能ですが、いくつかのサブコマンドだけでも、依存関係やスクリプトの管理においてかなり役立ちます。
行き詰まった時や、もっと多くの選択肢を試したい時は、どのコマンドでもヘルプフラグを受け付けます。 ランニング：
yarn --help
一般的なヘルプを出力しながら追加します --help 特定のサブコマンドの後には、状況に応じた使用方法のヒントが表示されます。 たとえば、 yarn install --help 依存関係のインストールプロセスで使用可能なすべてのフラグについて説明します。
全く新しいプロジェクトを立ち上げるには、Yarnに基本的な設定ファイルを生成させるように指示できます。 空のフォルダ内で、以下のコマンドを実行してください。
yarn init
このコマンドはいくつかのプロンプトに従って、 package.json プラス yarn.lock ファイルにソフトウェアを指定する必要があります。 前者はプロジェクトのメタデータ、スクリプト、依存関係を宣言するものであり、後者はインストール時に Yarn が解決した正確なバージョンの正規記録として機能します。
Yarnを使用している既存のリポジトリに参加する場合、一般的な出発点はすべての依存関係をインストールすることです。 プロジェクトのルートディレクトリから、以下のコマンドを実行します。
yarn install
ヤーンは次にこう読む package.json and yarn.lock不足しているものをダウンロードし、依存関係ツリーを設定します。 キャッシュのおかげで、CI環境下であっても、その後のインストールは初回実行時よりもはるかに高速になります。
新しい依存関係を追加するのも同様に簡単です。 add サブコマンド。 例えばExpressをインストールするには、以下の方法を使用します。
yarn add express
この単一のコマンドでパッケージを取得し、アップデートします package.json そしてリフレッシュ yarn.lock. JSONファイルを手動で編集する必要はありません。Yarnが宣言された範囲とロックされたバージョンを自動的に同期します。
簡単な健全性チェック：Yarn を使用した小型 Express サーバー
Yarnが意図どおりに動作していることを確実に確認したい場合は、Expressを使用して簡単な動作テストを作成できます。 プロジェクト内にいて、既に実行済みであると仮定します yarn add expressという名前のファイルを作成します index.js 以下の最小限のサーバー構成で：
const express = require("express");
const app = express();
app.get("/", (req, res) => res.send("Yarn is working!"));
app.listen(3000, () => console.log("Server running on http://localhost:3000"));
Nodeを直接呼び出す代わりに、Yarn経由でこのスクリプトを実行することもできます。これはPnP環境では便利です。 使用します。
yarn node index.js
別のターミナルを開き、サーバーが正しく応答することを確認してください。 シンプルな：
curl http://localhost:3000
「Yarnが動作しています！」というメッセージを返すはずです。 そうなれば、Yarnが依存関係を解決し、モジュール解決を適切に設定し、スクリプトを問題なく実行したことがわかります。
依存関係、スクリプト、および Yarn キャッシュの管理
Yarnは、インストールや基本的な機能追加に加えて、依存関係グラフをクリーンに維持・進化させるための様々なユーティリティを提供します。 これらのコマンドは手動編集を回避し、 package.json and yarn.lock 常に一貫性を保つ。
不要になった依存関係を削除するには、 remove サブコマンド。 具体的な例を挙げますと、以下の通りです。
yarn remove package-name
Yarn はパッケージをアンインストールし、 package.jsonそして、それに応じてロックファイルを更新します。 これにより、古くなったモジュールや使用されていないモジュールが依存関係ツリーに残るのを防ぎます。
依存関係のアップグレードは、一括で行うことも、特定のパッケージに対して行うことも可能です。 議論がなければ、
yarn upgrade
指定された範囲に従って互換性のある新しいバージョンを解決しますが、次の点も考慮する必要があります。
yarn upgrade package-name
単一の依存関係を対象とします。 どちらの場合も、Yarn は書き換えます yarn.lock 更新された依存関係グラフを反映するため。
プロジェクトでスクリプトを定義する場合 package.json、ヤーンの run サブコマンドは、それらを実行する方法です。 次のようなスクリプト：
"scripts": {
"start": "node index.js"
}
以下の方法で起動できます：
yarn run start
そして多くの場合、より短い yarn start aliasでも動作します。 これは、基盤となるモジュールリンク戦略に関係なく、Nodeやその他のツールの上にクリーンな抽象化レイヤーを提供します。
Yarnは、インストールを高速化し、オフラインでの動作を可能にするために、以前にダウンロードしたすべてのパッケージをローカルまたはグローバルなキャッシュに保持します。 特に実験後や複数回のバージョン切り替え後には、キャッシュが不安定になったり破損したりすることがあります。キャッシュに問題があると思われる場合は、以下のコマンドでリセットできます。
yarn cache clean
Yarnがキャッシュされたアーティファクトをどこに保存しているかに興味がある場合は、 yarn cache dir 場所を表示します。 これは、Windowsのウイルス対策ソフトでキャッシュフォルダをホワイトリストに登録する必要がある場合に特に便利です。そうすることで、ダウンロードしたすべてのファイルを過剰にスキャンすることによるインストール速度の低下を防ぐことができます。
.yarnrc.ymlを使用したYarnの設定
Modern Yarn はプロジェクト構成を一元化します .yarnrc.yml ファイルにソフトウェアを指定する必要があります。 このYAMLドキュメントは、依存関係のリンク方法、キャッシュの保存場所、PnPの厳密さ、レジストリURL、テレメトリなどを制御します。
典型的な構成は次のようになります。
nodeLinker: pnp
pnpMode: strict
compressionLevel: mixed
enableGlobalCache: true
enableTelemetry: false
その nodeLinker 設定は、モジュールの解決方法を定義するため、特に重要です。 有効なオプションは次のとおりです pnp （プラグアンドプレイで、 node_modules フォルダ）、 node-modules （従来のレイアウト）、場合によっては pnpm スタイルのリンカー。ハードコードされたツールとの互換性の問題が発生した場合 node_modules 仮定、切り替え node-modules 多くの場合、それらを解決します。
compressionLevel Yarnに対し、キャッシュされたパッケージをどの程度積極的に圧縮すべきかを指示します。 の値 0 最大速度のために圧縮を完全に無効にします。 1 ディスク使用量を最小限に抑えるために完全圧縮を強制し、 mixed 両方の要素のバランスを取っており、ほとんどのチームにとって賢明なデフォルト設定と言えるでしょう。
有効にします enableGlobalCache Yarnが複数のプロジェクト間で共有キャッシュディレクトリを再利用するようにする。 こうすることで、複数のリポジトリが同じライブラリに依存している場合、Yarnはそれらを複数回ダウンロードすることを避け、ネットワーク帯域幅とディスク容量の両方を節約できます。
最後に、 enableTelemetry Yarnが匿名の使用状況情報をメンテナーに送信するかどうかを制御します。 プライバシーや法令遵守上の理由から、この機能をオフにする企業も少なくありませんが、プロジェクトのロードマップ策定の指針としてオンにしておく企業もあります。いずれにしても、これは設定ファイル内の単なるフラグに過ぎません。
Git統合：コミットすべきものと無視すべきもの
Yarnは機械の一部を .yarn ディレクトリにおいては、バージョン管理に何を含めるかを慎重に検討することが重要です。 それらのファイルの中には絶対に追跡すべきものもあれば、キャッシュやビルド成果物など、リポジトリを肥大化させるだけのものもある。
最小限 .gitignore 多くのベリー社のプロジェクトで採用されている戦略は次のようになります。
.yarn/*
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions
.pnp.*
このパターンは全体を無視します .yarn フォルダだが、コミットする必要のあるサブディレクトリをホワイトリストに登録する。 その releases 例えば、このディレクトリにはプロジェクト固有のYarnバイナリが含まれています。これがないと、他の開発者がリポジトリをクローンした際に、まったく同じCLIバージョンを取得できない可能性があります。
ホワイトリストに登録されているその他のパスなど .yarn/plugins or .yarn/sdks カスタムプラグインとエディター統合を保持します。 バージョン管理下に置くことで、チーム全員が同じプラグインセットと言語ツールサポートを共有できるようになります。
その .pnp.* エントリとは、PnPモードを使用している場合に依存関係ツリーを記述するPlug'n'Playマニフェストファイルのことです。 これらをコミットすることは、再現可能なワークフロー、場合によってはインストール不要のワークフローを実現する上で不可欠です。CIや新しいクローンは、マニフェストを再生成することなく、プロジェクトをすぐに実行できます。
さらに、次のことも覚えておいてください。 yarn.lock それはあなたのリポジトリにおいて第一級市民です。 依存関係の変更に合わせて常にコミットおよび更新を行う必要があります。そうしないと、Yarnの決定論的な利点がすべて失われてしまいます。
Yarn vs npm：Yarnが真価を発揮する場面
YarnとnpmはどちらもNode.jsの依存関係を管理するという同じ根本的な問題を解決しますが、Yarnはいくつかの実用的な場面で差別化を図っています。 最も顕著な違いはパフォーマンスであることが多い。並列インストールとよりスマートなキャッシュ処理により、Yarnは大規模プロジェクトにおいてインストールを大幅に高速化することが多い。
ディスク使用量も大きな利点の一つであり、特にプラグアンドプレイを活用する場合はなおさらです。 排除することで node_modulesこれにより、一般的なプロジェクトではディスク容量を大幅に削減でき、PnPとうまく統合されたツールは、Nodeが深く反復的なディレクトリツリーをたどる必要がなくなるため、モジュール解決の高速化という恩恵を受けることができます。
ロックファイル動作に関して言えば、Yarnの yarn.lock コンパクトで決定論的な性質を持つため、広く評価されている。 解決に関する決定事項を明示的に記録することで、特定のバージョンが選択された理由を理解しやすくなり、バージョン競合のデバッグも容易になります。
モノレポは、Yarnがワークスペース機能のおかげで長年先行してきた分野です。 ワークスペースを使用すると、単一のリポジトリ内の複数のパッケージがロックファイルを共有し、依存関係が効率的にホイストされ、ローカルパッケージが定型的な設定なしに自動的にリンクされます。
Yarnが際立って優れている実際のユースケースとしては、複雑なCI/CD環境、大規模な共有コードベース、企業プロキシやカスタム証明書の背後にある環境などが挙げられます。 例えば、 yarn install --immutable CI の内部では、以下の場合にインストールが失敗することが保証されます。 yarn.lock ファイルが一致しません package.jsonこれは、依存関係の不整合が本番環境に反映される前に検出します。
一方で、npmは小規模なプロジェクトや、npmエコシステムに深く関わっているチームにとっては、依然として十分に有効な選択肢である。 依存関係ツリーがそれほど複雑でない少数のサービスのみを管理し、モノレポやPnPに大きく依存していない場合は、npmを使い続けることのシンプルさが、Yarnの高度な機能よりも優れているかもしれません。
オペレーティングシステム固有のインストールオプション
npm ベースのグローバル CLI のインストールはほぼすべての環境で動作しますが、Yarn は OS 固有のディストリビューションとスクリプトも提供しています。 これらは、ネイティブのパッケージマネージャーを好む場合や、便利なnpm環境が整っていないシステムで作業する場合に役立ちます。
macOSでは、Homebrew経由でYarnをインストールするのが非常に一般的な方法です。 Nodeが既にインストールされている（場合によってはHomebrew経由でも）ことを前提とした、一般的な流れは以下のとおりです。
brew install yarn
nvmなどのNodeバージョンマネージャーを使用する場合は、PATH環境変数でshimsディレクトリがHomebrew Nodeよりも前に設定されていることを確認してください。 そうしないと、Yarnスクリプトを実行する際に、想定とは異なるNode.jsバージョンが使用される可能性があります。
macOS におけるもう一つの選択肢は MacPorts です。MacPorts を使用すれば、Node.js と Yarn がまだインストールされていない場合にインストールできます。 さらに詳細な制御を可能にするため、YarnはmacOSおよび一般的なUnixで動作するインストール用シェルスクリプトも公開しています。このスクリプトをシェルにパイプすることで、Yarnのダウンロードとセットアップを一度に行うことができます。
Windowsの場合、推奨されるインストール方法は、MSIインストーラー、Chocolatey、またはScoopです。 MSIインストーラーはグラフィカルウィザードで手順を案内し、通常はプロセスの一環としてNode.jsがインストールされていることを確認します。一方、ScoopはコマンドラインからYarnをインストールでき、Nodeがインストールされていない場合はオプションでインストールを提案します。
Windows に Yarn をインストールする際は、プロジェクトフォルダと Yarn キャッシュディレクトリの両方をホワイトリストに登録することをお勧めします。通常、 %LocalAppData%\Yarnお使いのウイルス対策ソフトで。 そうしないと、すべてのファイルのダウンロードと書き込みがスキャンされ、インストール速度が著しく低下する可能性があります。
Linuxディストリビューションは、公式システムパッケージ、Yarn独自のレポジトリ、または手動のtarballインストールなど、複数のオプションを提供することが多い。 例えば、DebianやUbuntuでは、YarnのAPTリポジトリを追加し、必要に応じてNodeSourceを設定して最新のNode.jsを取得し、その後Yarnをインストールできます。 apt.
CentOS、Fedora、RHEL、Archなどのディストリビューションでは、YarnはGPG署名付きのtarballを提供しており、これをダウンロードしてディスク上の任意の場所に展開できます。 これらの手動設定では、通常、tarball の署名を GPG で検証し、展開された Yarn ディレクトリを PATH に追加する必要があります。 yarn このコマンドはシステム全体で利用可能です。
Unix、Linux、WindowsにおけるPATHの設定
インストール時によくある混乱の原因は、PATH の設定です。Yarn はインストールされているのに、シェルがバイナリを見つけられない場合があります。 その場合は、YarnディレクトリがPATH環境変数に含まれるように環境を更新する必要があります。
Unix 系システムでの手動 tarball インストールの場合、通常は Yarn のパスを指すパスをエクスポートします。 bin ディレクトリにあります。 具体的な例を挙げますと、以下の通りです。
export PATH="$PATH:/opt/yarn-[version]/bin"
この行をシェルプロファイルファイル（例： .bashrc, .bash_profile, .zshrc（または同様の）を実行し、新しいターミナルセッションを開くか、ファイルを読み込むことで変更を反映させます。 完了したら、 yarn --version どのディレクトリからでも動作するはずです。
もしあなたが寄りかかるなら yarn global コマンドを実行するには、Yarn のグローバル bin フォルダが PATH に含まれていることを確認する必要があります。 これを素早く実現する方法は、プロフィールに以下の情報を追加することです。
export PATH="$PATH:`yarn global bin`"
魚の殻を使う人は代わりに fish_user_paths そして、以下のことが可能になります。
set -U fish_user_paths (yarn global bin) $fish_user_paths
Windowsの場合、YarnのバイナリディレクトリをPATH環境変数に手動で追加する必要がある場合もあります。 簡単な例は次のようになります。
set PATH=%PATH%;C:\.yarn\bin
実際には、グラフィカルインストーラーやWindowsパッケージマネージャーがPATHの設定を自動的に行ってくれることが多いのですが、予期しない動作が発生した場合に手動で調整する方法を知っておくと便利です。
よくあるインストール時の問題とその解決方法
明確なドキュメントがあっても、チームがYarnを導入する際には、特定のインストール問題が繰り返し発生する。 幸いなことに、それらのほとんどには、よく理解されていて再現可能な解決策が存在する。
よくある問題の一つは、npm を介してグローバル CLI をインストールする際に発生する権限関連のエラーです。 npmのプレフィックスがシステム所有のディレクトリを指している場合、次のようなコマンドを実行します。
sudo npm install -g yarn
効果はあるかもしれないが、長期的には理想的ではない。 より良い方法は、npm を設定してユーザー所有のグローバルディレクトリを使用するようにすることです。現在のプレフィックスは、次のコマンドで確認できます。
npm config get prefix
もしそれが以下の何かを指している場合 /usr独自のディレクトリを作成し、npm を再設定してください。 例えば：
mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
export PATH=~/.npm-global/bin:$PATH
シェル設定を再読み込みした後、Yarnをグローバルにインストールできるようになります。 sudoこれにより、多くの権限に関する問題を回避できます。
もう一つよくある混乱の原因は、グローバルな Yarn とプロジェクト Yarn のバージョンの不一致です。 これは意図的なものであることに注意してください。グローバル 1.x CLI は単なるランチャーであり、Berry で構成されたプロジェクト内で使用される場合、そのリリースに委譲されます。 .yarn/releases.
Yarnがインストール成功を報告したにもかかわらずパッケージが不足しているように見える場合は、PnPをまだ理解していないツールに遭遇している可能性があります。 一部のエディタ、リンター、またはビルドツールは、 node_modules ディレクトリが存在しない場合は失敗します。一般的な解決策としては、エディタ用の Yarn SDK を有効にする、Yarn のサポート マトリックスから互換性のあるツールを使用する、または一時的にリンカーを切り替えることが挙げられます。 node-modules 、 .yarnrc.yml.
複数のブランチが並行して依存関係を追加または変更する活発なチームでは、ロックファイルの競合は避けられない。 日時 yarn.lock マージ中に競合が発生した場合、効果的な戦略は、1 つのブランチをベースラインとして選択し、可能な限りそのベースラインを優先してテキストの競合を手動で解決し、その後実行することです。 yarn install クリーンなロックファイルを再生成し、それを新たな信頼できる情報源として再度コミットします。
キャッシュ関連の問題は、通常は簡単な方法で解決できます。 yarn cache clean 続いて新鮮な yarn install. Yarnの動作がおかしかったり、パッケージが古く見えたり、奇妙な解決エラーが発生したりした場合は、キャッシュをクリアして再インストールすることで、多くの場合、それ以上の調査をしなくてもシステムが正常な状態に戻ります。
インストール後のチェックと継続的なパフォーマンス調整
Yarnがインストールされ、コマンドが正常に実行できるようになったら、プロジェクトに必要な設定がすべて正しく行われていることを確認するために、簡単なヘルスチェックをいくつか実行してみる価値があります。 最初にして最も簡単な手順は、バージョンを確認することです。
yarn --version
その後、既に package.json、実行中 yarn install エラーが発生しないということは、お使いの環境、レジストリへのアクセス、およびNodeのバージョンが互換性があることを示す強力な指標です。 依存関係が多い場合は、インストール時間に注意した方が良いでしょう。2回目以降の実行では、Yarnのキャッシュ機能と並行処理機能により、インストール時間が大幅に短縮されるはずです。
Yarn は次のようなコマンドも提供しています。 yarn outdated どのパッケージに新しいバージョンが利用可能かを確認するには、 yarn list --depth=0 実際にインストールされているすべての最上位依存関係を表示します。 これらのツールは、依存関係のずれを追跡し、アップグレードのスケジュールを決定するのに役立ちます。
パフォーマンスに関しては、インストール後に調整できる項目がいくつかあります。 設定例 networkConcurrencyカスタムキャッシュフォルダを使用したり、CIで詳細なプログレスバーを無効にしたりすることで、大規模なインストール時間を数秒、場合によっては数分短縮できます。たとえば、以下の方法で同時実行数を増やすと良いでしょう。
yarn config set network-concurrency 8
これにより、Yarnはより多くのネットワークリクエストを並列送信できるようになり、高速接続環境ではダウンロード速度が向上することがよくあります。
最後に、非常に大規模なモノレポやマルチ環境構成の場合、Yarnをスケーラブルなインフラストラクチャ（コンテナベースのCIパイプラインやクラウドビルドプラットフォームなど）と組み合わせることで、その決定論的でキャッシュに優しい設計を最大限に活用できます。 すべてのインストールはガイドされているため yarn.lock そしてPnPまたは node_modules メタデータや、CIノード間で共有されるキャッシュ、あるいはビルド間で再利用されるキャッシュは、インストール時間を大幅に短縮できる。
要するに、Yarnを正しくインストールする方法、プロジェクトごとに固定する方法、PATHと設定を調整する方法、そしてキャッシュ機能とワークスペース機能を活用する方法を理解するために時間をかけることは、すぐに報われる。 その結果、インストール時間の短縮、ビルドの予測可能性の向上、モノレポの使いやすさの向上、そしてチームメンバー、CI/CDシステム、本番環境間で再現しやすい依存関係管理ワークフローが実現します。
