---
title: "Yarn BerryとClassicの違い：4.18の既定設定・enableScripts・v1からの移行手順"
url: "https://www.issoh.co.jp/tech/details/9005/"
published: 2025-09-25
updated: 2026-10-24
categories: ["Node.js"]
publisher: "株式会社一創"
---

# 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もその延長です。

| 系統            | 版（2026-10-24時点）         | 状態         | リポジトリ         |
| ------------- | ----------------------- | ---------- | ------------- |
| Classic（v1）   | 1.22.22（2024-03-09）     | セキュリティ修正のみ | yarnpkg/yarn  |
| Berry（v2〜v4）  | 4.18.1（2026-09-24）      | 現行の安定版     | yarnpkg/berry |
| Berry 3.x     | 3.8.7                   | 旧版（v3タグ）   | yarnpkg/berry |
| Yarn 6（Rust版） | 6.0.0-rc.23（2026-10-14） | リリース候補     | yarnpkg/zpm   |

Berryの版はnpmの [@yarnpkg/cli-dist](https://registry.npmjs.org/@yarnpkg/cli-dist) の配布タグで確認でき、2026年10月24日時点で `latest` が4.18.1、`v3` が3.8.7です。

### Yarn Classic 1.22.22の保守状況

[Classicのリポジトリ](https://github.com/yarnpkg/yarn)の説明文は「`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": "yarn@4.18.1"` の形で書き込まれ、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](https://v6.yarnpkg.com/blog/2026-01-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のリリース](https://github.com/yarnpkg/zpm/releases)は6.0.0-rc.23が最新で、npmの `@yarnpkg/cli-dist` には5.x・6.xとも公開されていません。業務で使うのは4.x、と考えてよい段階です。

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

| 項目                 | Classic（1.22）       | Berry（4.18）            |
| ------------------ | ------------------- | ---------------------- |
| 設定ファイル             | .yarnrc / .npmrc    | .yarnrc.yml（.npmrcは無視） |
| 依存の配置              | node\_modules       | 既定はPnP（.pnp.cjs）       |
| 版の固定               | .yarnrcのyarn-path   | packageManager欄で固定     |
| 依存のスクリプト           | 実行する                | 新規は実行しない（4.14〜）        |
| グローバル導入            | yarn global add     | 削除（yarn dlxで代替）        |
| ロックファイル固定          | `--frozen-lockfile` | `--immutable`          |
| yarn versionのGit操作 | コミットとタグを作る          | 作らない                   |
| 対応Node.js          | 古い版も可               | 18.12以上（4.0〜）          |

### 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のコマンドとの対応

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

| Classic                     | Berry                                      |
| --------------------------- | ------------------------------------------ |
| `yarn global add`           | `yarn dlx`                                 |
| `yarn upgrade`              | `yarn up`                                  |
| `yarn outdated`             | `yarn upgrade-interactive`                 |
| `yarn audit`                | `yarn npm audit`                           |
| `yarn publish / login`      | `yarn npm publish / login`                 |
| `yarn install --production` | `yarn workspaces focus --all --production` |
| `yarn config set registry`  | `yarn config set npmRegistryServer`        |
| `yarn versions`             | 削除（`yarn --version`）                       |
| `yarn import`               | 削除（Classicで変換してから移行）                       |
| `yarn check`                | 削除（通常のinstallで検査）                          |

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 1.22.22        | Berry 4.18.1         |
| ----------- | ---------------------- | -------------------- |
| 引数なし        | 新しい版を対話で尋ねる            | エラーで停止               |
| パッチを上げる     | `yarn version --patch` | `yarn version patch` |
| 版を直接指定      | `--new-version 1.5.0`  | `yarn version 1.5.0` |
| Gitのコミット・タグ | v1.0.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）｜感染確認・対処と再発防止の設定](/tech/details/11649/)」にまとめています。

既存のロックファイル（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](https://github.com/yarnpkg/berry/pull/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
```

社内パッケージや開発版のように公開直後に使いたいものは、[設定リファレンス](https://yarnpkg.com/configuration/yarnrc)にあるとおり `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://git@github.com/...` の形も別に並べます。

```
# .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以降の導入](/tech/details/2765/)」で扱っています。

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の変更点を解説](/tech/details/17664/)」で整理しています。

### 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以降の既定変更](/tech/details/17919/)」を参照してください。

ワークスペースで `package.json` に `nohoist` を書いている場合も手直しが要ります。`nohoist` はReact Nativeをワークスペースで動かすためにClassicで作られた設定で、Berryでは読まれません。公式の移行ガイドは、`nohoist` を消して `.yarnrc.yml` に `nmHoistingLimits: workspaces` を書くよう案内しています（指定できるのは `none`・`workspaces`・`dependencies` の3つ）。[Flutter / React Native開発](/service/apps/cross%5Fplatform/)のようにモバイルアプリと共有パッケージを同じリポジトリに置く構成では、移行時にこの設定の書き換えを手順に入れておきます。`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実装・モノレポ運用を解説](/tech/details/17573/)」で比べられます。

失敗しやすいのは、移行で書き込まれた `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実装・モノレポ運用を解説](/tech/details/17573/)
- [npmとは？CLIとレジストリの役割・package.jsonとv12の変更点を解説](/tech/details/17664/)
- [corepack prepareは非推奨？後継のinstall -g・use・enableとpnpmの版管理、Node.js 25以降の導入](/tech/details/2765/)
- [モノレポ（Monorepo）とは？マルチレポとの違い・メリット・デメリットと導入手順](/tech/details/3934/)
- [Node.jsとは？仕組み・版の選び方・標準機能で動かす手順を実装目線で解説](/tech/details/17433/)

---

出典: [Yarn BerryとClassicの違い：4.18の既定設定・enableScripts・v1からの移行手順](<https://www.issoh.co.jp/tech/details/9005/>)（株式会社一創）