Unity がプロジェクトをロードするときに、Unity Package Manager はプロジェクトマニフェストを読み込み、ロードするパッケージのリストを計算します。ユーザーが Package Manager ウィンドウ からパッケージをインストールまたはアンインストールすると、Package Manager はそれらの変更をプロジェクトマニフェストファイルに保存します。プロジェクトマニフェストファイルは 依存関係 オブジェクトを通してパッケージのリストを管理します。
さらに、プロジェクトマニフェストは Package Manager の構成ファイルとしても機能します。Package Manager はマニフェストを使用してレジストリ URL をカスタマイズし、カスタムレジストリを登録します。
manifest.json というプロジェクトマニフェストファイルは Unity プロジェクトのルートフォルダー下の Packages フォルダー内にあります。パッケージマニフェストファイルと同様に、プロジェクトマニフェストファイルは JSON (JavaScript Object Notation) 構文を使用します。
すべてのプロパティは必須ではありません。ただし、プロジェクトマニフェストファイルに値がまったく含まれていない場合、Package Manager ウィンドウは起動せず、Package Manager はパッケージをロードしません。
ヒント: Unity のメイン Help メニュー から Reset packages to defaults を選択することで、いつでもレジストリの問題を修正することができます。ただし、これを行うと、プロジェクトの依存関係に加えたすべての変更がリセットされるため、この方法は最後の手段として使用すべきです。
| キー | JSON 型 | 説明 |
|---|---|---|
| ** の依存関係** | オブジェクト | プロジェクトに必要なパッケージのコレクション。これには、直接の依存関係のみが含まれています (間接的な依存関係は、パッケージマニフェスト に記載されています)。各エントリーは、パッケージ名 を、プロジェクトに必要な最低限の バージョン にマップします。{<br /> “com.my-package”: “2.3.1”,<br /> “com.my-other-package”: “1.0.1-preview.1”,<br /> etc.<br /> }<br />}<br /><br />バージョン番号を指定することは、Package Manager がパッケージレジストリからパッケージをダウンロードすることを意味します (つまり、パッケージの [ソース](upm-concepts.html#Sources) はレジストリです)。ただし、[バージョン](upm-manifestPkg.html#version) を使用するだけでなく、[ローカルフォルダーや .tgz ファイルへのパス](upm-localpath.html) や [Git URL](upm-git.html) を指定することもできます。<br /><br />**ノート**: Package Manager は、自動的に [埋め込み](upm-embed.html) パッケージをプロジェクトのPackagesフォルダー内で見つけてロードするので、パッケージを指定する必要はありません。Package Manager は、それ自体のパッケージマニフェストに同じ [名前](upm-manifestPkg.html#name) の埋め込みパッケージがある場合、どのエントリーも無視します。 |
| <a name="registry"></a>**registry** | 文字列 | URL of the main Unity Package Manager registry. This overrides the default registry URL (https://packages.unity.com). <br /><br />**Note**: If you override the default registry with your own registry, you lose access to the official Unity packages. Instead, if you want to augment the Unity package library with your own private collection of packages, set the __scopedRegistries__ property to use a scoped registry instead. |
| <a name="scopedRegistries"></a>** scopedRegistries** | オブジェクトの配列 | デフォルトのレジストリに加えて、カスタムのレジストリを指定します。これにより、独自のパッケージをホストすることができます。<br/><br/>詳細は[スコープ付きレジストリ](upm-scoped.html)を参照してください。 |
| <a name="testables"></a>**testables** | 文字列の配列 | Unity [Test Framework](https://docs.unity3d.com/Packages/com.unity.test-framework@latest) にロードしたいテストを持つパッケージの名前を列挙します。詳細は、[パッケージにテストを加える](cus-tests.html) を参照してください。<br /><br />**ノート**: Unity Test Framework は、[埋め込み](upm-embed.html) パッケージはデフォルトでテスト可能であるとみなすため、それらを指定する必要はありません。 |
| <a name="enableLockFile"></a>**enableLockFile** | ブーリアン | ロックファイルを有効にして、依存関係を決定論的に解決します。これは、デフォルトではtrueに設定されています。詳細については、[ロックファイルの使用](upm-conflicts-auto.html) を参照してください。 |
| <a name="resolutionStrategy"></a>**resolutionStrategy** | 文字列 | セマンティックバージョニングのルールに基づいて、[間接的な依存関係](upm-dependencies.html) をアップグレードします。これは、デフォルトではlowestに設定されています。詳細については、[解決法の設定](#strategize) を参照してください。 |
| <a name="useSatSolver"></a>** useSatSolver** | ブーリアン | [SAT ソルバーベース](upm-conflicts.html) の依存関係解決アルゴリズムを有効にします。これはデフォルトでtrueに設定されています。<br /><br />このプロパティをfalse` に設定すると、Package Manager は代わりに非推奨の 深度ベースの方法 を使用します。 |
{
"registry": "https://my.registry.com",
"scopedRegistries": [{
"name": "My internal registry",
"url": "https://my.internal.registry.com",
"scopes": [
"com.company"
]
}],
"dependencies": {
"com.unity.package-1": "1.0.0",
"com.unity.package-2": "2.0.0",
"com.company.my-package": "3.0.0",
"com.unity.my-local-package": "file:<path>/my_package_folder",
"com.unity.my-local-tarball": "file:<path>/my_package_tarball.tgz",
"com.unity.my-git-package": "https://my.repository/my-package.git#v1.2.3"
},
"enableLockFile": true,
"resolutionStrategy": "highestMinor",
"testables": [ "com.unity.package-1", "com.unity.package-2" ]
}
間接的な依存関係をアップグレードするために、パッケージのバージョンをプロジェクトマニフェストに明示的に加えて、Unity のパッケージ依存関係の解決をオーバーライドすることもできますが、これは以下の 2 つの理由からあまり良い方法と言えません。
より良い方法は、resolutionStrategy プロパティを設定することによって、Package Manager が間接的な依存関係を選択する方法をカスタマイズすることです。
| 値 | 説明 |
|---|---|
| lowest | 間接的な依存関係をアップグレードしません。代わりに、要求されたバージョンをそのまま使用します。これがデフォルトのモードです。 |
| HighPatch | 同じメジャーコンポーネントとマイナーコンポーネントを持つ最高のバージョンにアップグレードします。たとえば、必要なバージョンが 1.2.3 の場合、この方法では [1.2.3, 1.3.0] の範囲内 (つまり、>= 1.2.3 かつ < 1.3.0) で、最も高いバージョンが選択されます。 |
| HighestMinor | 同じメジャーコンポーネントを持つ最高のバージョンにアップグレードします。たとえば、要求されたバージョンが 1.2.3 の場合、この方法では [1.2.3, 2.0.0] の範囲内 (つまり、>= 1.2.3 かつ < 2.0.0) で、最も高いバージョンが選択されます。ノート: バージョン 1.0.0 は、最初の安定した本番環境可能なバージョンを示しています。それより下のバージョン 0.X.Y は、その API がまだ安定していないことを示しており、続くマイナーバージョンでは破壊的変更が発生する可能性があります。セマンティックバージョニング仕様のこの部分は、迅速な開発を妨げることなくパッケージの初期バージョンをリリースすることを可能にしています。このため、ターゲットバージョンが 0.X.Y の場合、highestMinor は highestPatch のように動作し、後方互換性を持つバージョンの選択を保証します。例えば、要求されたバージョンが 0.1.3 の場合、この方法は [0.1.3, 0.2.0] の範囲で最も高いバージョンを選択します。 |
| highest | 最高のバージョンにアップグレードします。例えば、必要なバージョンが 1.2.3 の場合、この方法では [1.2.3, 2.0.0] の範囲 (つまり、>= 1.2.3 かつ上限なし) で最高バージョンを選択します。 |
ノート: これらの範囲によって、依存関係が安定したリリースから プレビュー パッケージに替わることはありません。