Yarn BerryとClassicの違い：4.18の既定設定・enableScripts・v1からの移行手順

Yarn（読み方はヤーン）はNode.jsのパッケージマネージャで、2016年に公開され2017年9月に1.0となった1.x系のYarn Classicと、2.0以上6.0未満のYarn Berry（公式ドキュメントでは Yarn Modern とも呼ぶ）の2系統があります。2026年10月24日時点の最新版はBerry系の4.18.1（2026年9月24日公開）で、Classicは2024年3月の1.22.22が最後のリリースです。

この記事では、両者の違いを設定ファイル・インストール方式・コマンドの3点で整理し、4.14以降に既定値が変わった enableScripts と npmMinimalAgeGate の扱い、Classicやnpmからの移行手順をまとめます。手順とエラーメッセージは、Yarn 4.18.1・1.22.22とNode.js v26.5.0（macOS・x64）で実行して確認したものです。後述の @esbuild/darwin-x64 を使う例は、別のOSやCPUではパッケージ名が変わります。

まとめ：Yarn BerryとClassicの違いと移行の要点

• 現行版はBerry系の4.18.1。Classic（1.22.22）は機能追加と通常のバグ修正が凍結され、受け付けるのはセキュリティ修正のみです。新規プロジェクトで選ぶ理由はありません。
• Berryの既定は nodeLinker: pnp（node_modulesを作らない）。互換性が問題なら nodeLinker: node-modules の1行でClassicと同じ配置に戻せます。
• 4.14.0から、新規プロジェクトでは依存パッケージのpostinstall等が既定で実行されません。必要なパッケージだけ dependenciesMeta の built: true で許可します。GitHub上のGit依存も approvedGitRepositories で許可するまで取得できません。
• 4.15.0から、新規プロジェクトでは公開後1日未満の版がインストール候補から外れます（npmMinimalAgeGate: 1d）。除外したいパッケージは npmPreapprovedPackages に書きますが、プラットフォーム別の依存パッケージ名も並べる必要があります。
• 既存のロックファイルがあるプロジェクトを4.18.1で更新すると、.yarnrc.yml に enableScripts: true と npmMinimalAgeGate: 0 が書き込まれ、従来の動作が維持されます。
• yarn version は版の表示ではなく package.json の版を書き換えるコマンドです。版の確認は yarn --version を使います。
• Node.js 25以降はCorepackが同梱されないため、npm install -g corepack を先に実行します。
• 移行は yarn set version berry → .yarnrc.yml への設定移し替え → yarn install の順。CIの --frozen-lockfile は --immutable に置き換えます。

Yarnの版系統：Classic・Berry・Yarn 6の現状

「Yarn 2」「Yarn v2」「Berry」は同じ系統を指します。2.0で全面的に書き直されたコードベースが yarnpkg/berry リポジトリで開発されており、3.x・4.xもその延長です。

Berryの版はnpmの @yarnpkg/cli-dist の配布タグで確認でき、2026年10月24日時点で latest が4.18.1、v3 が3.8.7です。

Yarn Classic 1.22.22の保守状況

Classicのリポジトリの説明文は「The 1.x line is frozen - features and bugfixes now happen on https://github.com/yarnpkg/berry」です。READMEには「The 1.x codebase is fairly old and will only accept security fixes.」とあり、受け付けるのはセキュリティ修正だけです。1.xで不具合に当たったら最新版へ移行するよう勧めています。npmレジストリの yarn パッケージは今も latest が1.22.22を指しているため、npm install -g yarn で入るのはClassicです。

手元のYarnの版を確認する方法

Berryでは版がプロジェクトごとに固定されます。yarn init や yarn set version を実行すると、package.json に "packageManager": "[email protected]" の形で書き込まれ、Corepackがこの値を読んで同じ版を起動します。確認と更新は次のとおりです。

yarn --version            # プロジェクトで有効な版（例: 4.18.1）
yarn set version stable   # 最新の安定版へ更新
yarn install

yarn set version berry も現行の安定版を指し、実行すると4.18.1が入ります。ハイフンの無い yarn version は版を表示するコマンドではありません。Berryでは引数なしで実行すると「Not enough positional arguments.」で止まります（次章で扱います）。Classicにあった yarn versions（Node.jsなどの版を一覧表示）は2.x以降で削除され、yarn --version と node -p process.versions で代えます。

Yarn 6（Rust版）と5.xの計画

メンテナのMaël Nison氏は2026年1月28日の公式ブログ「Yarn 6 Preview」で、YarnをRustへ移植すると発表しました。同記事のベンチマークでは、Next.jsプロジェクトのウォームキャッシュ時のインストールが577ms（従来版）から184ms（Rust版）に、pnpmは686msでした。

同記事の計画では、JavaScript実装は移行の足場となる5.x系まで続き、6.x安定版は早くても2026年第3四半期以降とされています。6.x安定版の公開後、5.xは約30か月の重大バグ修正のみのLTSになります。6.xでは、Corepackに代わる版切り替えツール「Yarn Switch」を用意し、ゼロインストールに代わる「Lazy Installs」を既定にする予定です。2026年10月24日時点で yarnpkg/zpmのリリースは6.0.0-rc.23が最新で、npmの @yarnpkg/cli-dist には5.x・6.xとも公開されていません。業務で使うのは4.x、と考えてよい段階です。

BerryとClassicの違い：インストール方式・設定ファイル・コマンド

nodeLinkerの3方式とPnPの厳格さ

Berryは .yarnrc.yml の nodeLinker で依存の置き方を選べます。pnp（既定）は .pnp.cjs 1ファイルで依存の場所を解決し、pnpm はグローバルストアへのハードリンクとシンボリックリンクで node_modules を作り、node-modules はClassicやnpmと同じ配置です。

PnPは package.json に書いていないパッケージの読み込みをエラーにします。esbuildだけを追加した状態で、esbuildが間接的に依存する @esbuild/darwin-x64 を直接 require すると、次のエラーで止まりました。

Error: Your application tried to access @esbuild/darwin-x64, but it isn't declared in your dependencies; this makes the require call ambiguous and unsound.

Classicでは偶然巻き上げられたパッケージを宣言なしで読めてしまい（ファントム依存）、依存先の更新で突然壊れる原因になっていました。PnPはこれを最初から許しません。一方、PnPに未対応のツールがあるなら、次の1行で解決します。同じコードは node_modules 配置では通りました。

# .yarnrc.yml
nodeLinker: node-modules

VS Code等でPnPの型解決が効かない場合は yarn dlx @yarnpkg/sdks vscode でエディタ用の設定を生成します。

ゼロインストールは4.0から既定外

依存のキャッシュ（.yarn/cache）をGitに含めてインストールを省く「ゼロインストール」は、2.x時代のBerryの看板機能でした。4.0.0で yarn init の既定から外れ、キャッシュはプロジェクト外のグローバルフォルダに置く設定（enableGlobalCache: true）が既定になっています。yarn init が生成する .gitignore には「ゼロインストールを使うなら行を入れ替え、yarn config set enableGlobalCache false を実行する」というコメントが入ります。リポジトリの肥大化を受け入れられる場合だけ有効にする機能です。

Classicのコマンドとの対応

公式の移行ガイドが挙げる主な置き換えです。yarn dlx は一時環境にパッケージを取得して実行するコマンドで、グローバルに常設する yarn global add と同じ動作ではありません。CLIを常用するなら、プロジェクトの devDependencies に入れて yarn run で呼びます。

4.18.1で古い書き方を実行すると、yarn global add は「The 'yarn global' commands have been removed in 2.x」で、yarn config set registry は「Couldn't find a configuration settings named "registry"」で止まります。削除された yarn import や yarn versions は、同名のスクリプトを探しに行って「Couldn't find a script named "import".」と表示されます。--frozen-lockfile は警告YN0050を出したうえで実行されますが、--immutable へ書き換えるべきです。CI環境（環境変数 CI=true）では enableImmutableInstalls が既定で true になるため、フラグなしでもロックファイルの変更は拒否されます。

4.0.0からは公式プラグインがすべて本体に同梱されたので、yarn upgrade-interactive を使うために yarn plugin import interactive-tools を実行する手順は不要です。yarn plugin import が必要なのはサードパーティ製プラグインだけです。

yarn versionコマンドの挙動の違い（Gitタグ・引数・deferred）

yarn version は、自分のパッケージの package.json にある version を書き換えるコマンドです。名前は同じでも、ClassicとBerryで動きがかなり違います。1.22.22と4.18.1で実行した結果は次のとおりです。

Classicは既定でコミットとタグ（v1.0.1）を作るため、リリース用スクリプトがこのタグに頼っていることがあります。Berryの yarn version patch は package.json を変更するだけで、git status には未コミットの変更として残りました。移行後にタグが付かなくなったら、git tag を自分で呼ぶ処理を足します。version フィールドの無いパッケージで yarn version patch を実行すると「Can't bump the version if there wasn't a version to begin with」で止まるので、最初は yarn version 1.0.0 のように版を直接指定します。

Berryには、版上げの予定だけを記録しておく --deferred があります。yarn version minor --deferred を実行すると .yarn/versions/ に releases: を書いたファイルができ、package.json は変わりません。後で yarn version apply を実行した時点で版が上がりました（2.0.0→2.1.0）。モノレポで複数パッケージの版上げをプルリクエストごとに積み上げ、リリース時にまとめて適用する使い方を想定した機能です。

Yarn 4.14以降のセキュリティ既定：enableScriptsとnpmMinimalAgeGate

4.14.0（2026年4月16日）以降、インストールの既定動作がサプライチェーン攻撃を想定したものに変わりました。ただし、既存のロックファイルがあるプロジェクトでは移行処理が従来の値を .yarnrc.yml に書き込むため、新しい既定値は効きません。2026年3月のaxios乗っ取りの経緯と、npm・pnpm側の同種の設定は「axiosにマルウェア混入（1.14.1・0.30.4）｜感染確認・対処と再発防止の設定」にまとめています。

既存のロックファイル（Classicの yarn.lock または4.13以前のBerryのもの）があるプロジェクトを4.18.1で yarn install すると、「YN0087: Migrated your project to the latest Yarn version」と表示され、.yarnrc.yml に次の3項目が追加されました。Classicからの移行でも4.13.0からの更新でも同じ結果です。

approvedGitRepositories:
  - "**"
enableScripts: true
npmMinimalAgeGate: 0

つまり既存プロジェクトでは従来の動作が維持されます。新しい既定値に揃えるには、上記の3項目を配列の要素ごと削除するか、それぞれ新しい値を明示します。yarn.lock の無いプロジェクトでは何も書き込まれず、新しい既定値がそのまま効きました。

enableScriptsの既定falseと個別に許可する書き方

PR #7089で、依存パッケージの preinstall・install・postinstall は既定で実行されなくなりました。メンテナはPRで「次のメジャー版まで待つ予定だったが、パッケージ乗っ取りが続くので前倒しした」という趣旨を述べています。自分のワークスペースのスクリプトは従来どおり実行されます。

yarn init で作った新規プロジェクトにesbuild 0.25.0を追加すると、インストールは成功したうえで次の警告が出ました。

➤ YN0004: │ esbuild@npm:0.25.0 lists build scripts, but all build scripts have been disabled.

ネイティブアドオンのビルドやバイナリの取得をpostinstallで行うパッケージは、この状態では動かないことがあります。全体を enableScripts: true に戻すのではなく、必要なパッケージだけを package.json で許可します。

{
  "dependencies": {
    "esbuild": "0.25.0"
  },
  "dependenciesMeta": {
    "esbuild": {
      "built": true
    }
  }
}

この状態で yarn install を実行すると「YN0007: esbuild@npm:0.25.0 must be built because it never has been before or the last one failed」と表示され、esbuildのスクリプトだけが実行されました。同じ4.14.0で、exec: プロトコルも enableScripts に従うようになっています。

公開1日未満の版を除外するnpmMinimalAgeGateとnpmPreapprovedPackages

4.10.0で入った npmMinimalAgeGate は、公開から指定時間が経っていない版をインストール候補から外す設定です。4.15.0で既定値が 1d になりました（yarn config get npmMinimalAgeGate は分単位の 1440 を返します）。公開直後の版をすぐに取り込まず、不正な版が発見・削除されるまでの猶予を設けるための設定です。

新規プロジェクトで、当日公開されたTypeScriptの開発版（typescript@next＝7.1.0-dev.20261024.1）を追加すると、候補がすべて除外されて失敗しました。

➤ YN0016: All versions satisfying "^7.1.0-dev.20261024.1" are quarantined

社内パッケージや開発版のように公開直後に使いたいものは、設定リファレンスにあるとおり npmPreapprovedPackages にパッケージ名かグロブパターンを書くと判定から外れます。注意したいのは、本体の名前だけでは足りない場合があることです。"typescript" だけを書いた状態では、今度は依存するプラットフォーム別パッケージ @typescript/typescript-darwin-arm64 が同じYN0016で止まりました。スコープごと許可する行を足すとインストールが通りました。

# .yarnrc.yml
npmPreapprovedPackages:
  - "typescript"
  - "@typescript/*"

esbuildやSWCのように、本体がOSとCPUごとのバイナリを別パッケージで配る製品は同じ構造です。YN0016の行に出たパッケージ名を見て、例外にする必要を確認したものだけを書き足してください。スコープ単位の指定はプラットフォーム別パッケージが多い場合に限り、そのスコープの他のパッケージまで公開直後の版を許可することを承知のうえで使います。既存プロジェクトでは移行時に npmMinimalAgeGate: 0 が書き込まれ、この遅延は効きません。CIでは yarn config get enableScripts と yarn config get npmMinimalAgeGate で実効値を確認し、どちらの値で運用するかを .yarnrc.yml に明示してください。

Git依存を許可するapprovedGitRepositories

4.14.0で追加された approvedGitRepositories は、取得してよいGitリポジトリのURLをグロブで並べる設定です。新規プロジェクトの既定値は空の配列で、設定リファレンスにも「GitHub repositories must be explicitly approved」とあります。実際に yarn add is-number@github:jonschlinkert/is-number を実行すると、次のエラーで止まりました。

➤ YN0080: │ is-number@github:jonschlinkert/is-number: Request to 'https://github.com/jonschlinkert/is-number.git' has been blocked because it doesn't match any of the patterns in 'approvedGitRepositories'

パターンはエラーに出た正規化後のURL（https:// で始まり .git で終わる形）に対して書きます。次の2行を足すと同じコマンドが成功しました。SSHで取得する依存があるなら ssh://[email protected]/... の形も別に並べます。

# .yarnrc.yml
approvedGitRepositories:
  - "https://github.com/jonschlinkert/*"

移行時に書き込まれる "**" はすべてのリポジトリを許可する値です。Git依存を使っていないプロジェクトなら、この行を消しても影響はありません。

Yarnのインストール：Node.js 25以降はCorepackが別途必要

Node.js 25.0.0（2025年10月15日）で、Corepackは同梱されなくなりました（変更履歴の「build: stop distributing Corepack」）。Corepackを同梱していたNode.js 24までの版（14.19・16.9以降）では corepack enable だけで使えましたが、25以降は先にCorepackを入れます。Yarnの公式インストール手順も次の形です。

npm install -g corepack
corepack enable
yarn init -2      # 新規プロジェクトをBerryで作成

Corepackが無い環境で yarn set version berry を実行すると、「You don't seem to have Corepack enabled; we'll have to rely on yarnPath instead」と表示され、.yarn/releases/yarn-4.18.1.cjs を保存して .yarnrc.yml の yarnPath から参照する方式に切り替わりました。この .cjs ファイルと .yarnrc.yml をリポジトリに含めれば、Corepackが無くても node .yarn/releases/yarn-4.18.1.cjs で同じ版を起動できます。yarn コマンドで呼ぶには、yarnPath を読んで処理を委譲するYarn（グローバルのClassic等）が別に必要です。Corepackの導入と後継コマンドは「corepack prepareは非推奨？後継のinstall -g・use・enableとpnpmの版管理、Node.js 25以降の導入」で扱っています。

Classicが必要な既存案件では npm install -g yarn で1.22.22が入ります。プロジェクト単位でClassicに固定するなら yarn set version classic を使います。なお、npmの yarn パッケージにある berry タグは2021年9月公開の2.4.3を指したままなので、npm install -g yarn@berry で現行のBerryは入りません。

Classic（v1）とnpmからBerry（v4）への移行手順

公式の移行ガイドは、最初は node_modules のまま移行し、PnPへの切り替えは後で判断するよう勧めています。この順番なら、ビルドが壊れたときに原因を版の変更とPnPのどちらかに絞り込めます。

Classicのプロジェクトを移す7ステップ

1. Node.js 18.12以上であることを確認し、Corepackを有効にする（Node.js 25以降は npm install -g corepack が先）。
2. プロジェクトで yarn set version berry を実行する。
3. .yarnrc.yml を作り、nodeLinker: node-modules を書く。
4. .npmrc・.yarnrc の設定を .yarnrc.yml に移す（レジストリは npmRegistryServer、認証トークンは npmAuthToken）。
5. yarn install でロックファイルを新形式に変換する。このとき .yarnrc.yml に enableScripts: true と npmMinimalAgeGate: 0 が書き込まれる。
6. スクリプトを個別許可に切り替えるなら enableScripts: true を消して再インストールし、YN0004が出たパッケージのうち、処理内容を確認して必要と判断したものだけに dependenciesMeta の built: true を設定する。
7. CIのコマンドを置き換え、変更をまとめてコミットする。

# .yarnrc.yml（移行直後の最小構成）
nodeLinker: node-modules
npmRegistryServer: "https://registry.npmjs.org"

npmからの移行：package-lock.jsonの互換性と依存版の再解決

Berryには yarn import がありません。公式の移行ガイドは「Classicでimportしてから移行する」よう案内していますが、npm 11.17.0が作った package-lock.json（lockfileVersion: 3）をClassic 1.22.22の yarn import にかけると、「Failed to import from package-lock.json, source file(s) corrupted」で失敗しました。少なくとも今回検証したlockfileVersion 3では、この経路をそのまま使えません。

その場合は packageManager と .yarnrc.yml を用意して yarn install を実行し、yarn.lock を新しく作ります。解決される版は package.json の範囲指定から選び直されるので、npm時代と版がずれることがあります。npm ls --all と yarn info --all --recursive の出力を比べ、メジャー版が変わった依存が無いかを確認してからコミットしてください。npm側の仕組みは「npmとは？CLIとレジストリの役割・package.jsonとv12の変更点を解説」で整理しています。

CIとワークスペースで書き換える設定

CIで見落としやすいのは次の3点です。

• yarn install --frozen-lockfile を yarn install --immutable に変える。
• 独自スクリプトの prestart 等は自動実行されないので、"start": "yarn prestart && http-server" のように明示的に呼ぶ（preinstall・postinstall は対象外）。
• キャッシュ対象は yarn config get cacheFolder の出力先にする（enableGlobalCache: true ではプロジェクト内の .yarn/cache は使われない）。

GitHub Actionsで組む場合は、actions/setup-node の cache: yarn がBerryのキャッシュ位置を扱えます。入力の詳細は「actions/setup-nodeとは｜v7の入力・キャッシュ設定とv5以降の既定変更」を参照してください。

ワークスペースで package.json に nohoist を書いている場合も手直しが要ります。nohoist はReact Nativeをワークスペースで動かすためにClassicで作られた設定で、Berryでは読まれません。公式の移行ガイドは、nohoist を消して .yarnrc.yml に nmHoistingLimits: workspaces を書くよう案内しています（指定できるのは none・workspaces・dependencies の3つ）。Flutter / React Native開発のようにモバイルアプリと共有パッケージを同じリポジトリに置く構成では、移行時にこの設定の書き換えを手順に入れておきます。bundleDependencies も node_modules を前提にした仕組みのため、移行ガイドはフォークか file: プロトコルでの置き換えを勧めています。

Berryへ移行しない判断：Classicに残る条件とpnpmを選ぶ条件

Classicに残ってよいのは、近く廃止するリポジトリで依存の更新もしない場合だけです。Classicの通常のnode_modules配置ではファントム依存を防げず、依存スクリプトも既定で実行されますが、--ignore-scripts で無効化できます。READMEはセキュリティ修正を受け付けるとしていますが、最後のリリースは2024年3月の1.22.22です。依存を更新し続けるプロジェクトをClassicのまま運用するのは避けるべきです。

移行先をBerryにするかpnpmにするかは、PnPを採用するかどうかと、採用するフレームワークやCIの公式手順との相性で決めます。PnPの厳格な依存チェックやゼロインストールを使わず、node_modules 互換の配置とディスク節約だけが目的なら、Berryの nodeLinker: pnpm でも実現できますが、採用予定のフレームワークやCIサービスがpnpmを公式手順として案内しているなら、pnpm本体を選ぶ方が手順どおりに組めます。pnpmの仕組みは「pnpmとは？共有ストアの仕組みとv12のRust実装・モノレポ運用を解説」で比べられます。

失敗しやすいのは、移行で書き込まれた enableScripts: true を不要な設定だと思って消したときです。新しい既定値が効いてスクリプトが止まりますが、インストール自体は成功し警告YN0004が出るだけなので、postinstallでバイナリを用意するパッケージが動かないことに、ビルドや実行の段階で初めて気づきます。npmMinimalAgeGate: 0 や approvedGitRepositories の "**" を消した場合も同じで、公開1日未満の版とGitHub上のGit依存が取得できなくなります。yarn.lock を削除して作り直しても、.yarnrc.yml に書き込まれた値が残っていれば従来の動作のままです。設定を変えたら、yarn install の出力にYN0004・YN0016・YN0080が出ていないかを必ず確認してください。

Yarn BerryとClassicに関するよくある質問

Yarn BerryとYarn 2は同じものですか？

同じ系統です。2.0で書き直されたコードベースの開発名がBerryで、3.x・4.xを含む2以上6未満の版をまとめてこう呼びます。Rust版の6.xは別リポジトリ（yarnpkg/zpm）で開発されています。

yarn set version berry を実行すると何が入りますか？

現行の安定版です。2026年10月24日時点では4.18.1が入ります。yarn set version stable と同じ結果になり、Classicに戻すときは yarn set version classic を使います。

--frozen-lockfile と --immutable の違いは何ですか？

どちらもロックファイルの変更を禁止するフラグで、Berryでは --immutable が正式名です。4.18.1で --frozen-lockfile を渡すと、非推奨の警告YN0050を出したうえで実行されます。

enableScriptsはtrueに戻すべきですか？

戻さず、必要なパッケージだけ dependenciesMeta の built: true で許可するのが4.14以降の想定された使い方です。.yarnrc.yml で enableScripts: true にすると、dependenciesMeta の built: false で個別に禁止したもの以外の依存スクリプトがすべて実行されます。既存プロジェクトは移行時に true が書き込まれているので、意図して残すのか確認してください。

Yarn Classicのインストール方法は？

npm install -g yarn で1.22.22が入ります。npmレジストリの yarn パッケージの latest は今もClassicを指しており、Berryはこの方法では入りません。

関連記事

• pnpmとは？共有ストアの仕組みとv12のRust実装・モノレポ運用を解説
• npmとは？CLIとレジストリの役割・package.jsonとv12の変更点を解説
• corepack prepareは非推奨？後継のinstall -g・use・enableとpnpmの版管理、Node.js 25以降の導入
• モノレポ（Monorepo）とは？マルチレポとの違い・メリット・デメリットと導入手順
• Node.jsとは？仕組み・版の選び方・標準機能で動かす手順を実装目線で解説