Project manifest file
Learn the properties of the file that the Package Manager reads to compute a list of packages to retrieve and load for a project.
阅读时间5 分钟最后更新于 1 个月前
When Unity loads a project, the Unity Package Manager reads the project manifest so that it can compute a list of which packages to retrieve and load. When a user installs or uninstalls a package through the Package Manager window, the Package Manager stores those changes in the project manifest file. The project manifest file manages the list of packages through the dependencies object.
In addition, the project manifest serves as a configuration file for the Package Manager, which uses the manifest to customize the registry URL and register custom registries.
You can find the project manifest file, called , in the folder under the root folder of your Unity project. Like the package manifest file, the project manifest file uses JSON (JavaScript Object Notation) syntax.
manifest.jsonPackagesProperties
All properties are optional. However, if your project manifest file does not contain any values, the Package Manager window doesn't load, and the Package Manager doesn't load any packages.
Key | JSON Type | Description |
|---|---|---|
| dependencies | Object | Collection of packages required for your project. This includes only direct dependencies (indirect dependencies are listed in package manifests). Each entry maps the package name to the minimum version required for the project:Specifying a version number indicates that you want the Package Manager to download the package from the package registry (that is, the source of the package is the registry). However, in addition to using versions, you can also specify a path to a local folder or tarball file, or a Git URL. Note: You do not need to specify embedded packages here because the Package Manager finds them inside your project's |
| enableLockFile | Boolean | Enables a lock file to ensure that dependencies are resolved in a deterministic manner. This is set to |
| resolutionStrategy | String | Upgrades indirect dependencies based on Semantic Versioning rules. This is set to |
| scopedRegistries | Array of Objects | Specify custom registries in addition to the default registry. This allows you to host your own packages. Refer to Scoped Registries for more details. |
| testables | Array of Strings | Lists the names of packages whose tests you want to load in the Unity Test Framework. For more information, see Adding tests to a package. Note: You do not need to specify embedded packages here because the Unity Test Framework assumes they are testable by default. |
| pinnedPackages | Array of Strings | Lists the names of packages that you want to lock at the version specified in the Adding package names to this list makes Package Manager use the exact package version specified in the |
Example
{ "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" ], "pinnedPackages": ["com.unity.package-1"]}
Setting a resolution strategy
While you can force Unity's package dependency resolution to use higher versions of indirect dependencies by adding them explicitly to the project manifest, this isn't a good strategy, for two reasons:
- It puts more responsibility on the project owner to maintain dependency versions.
- Over time, you might have dependencies that are not required by the project.
A better approach is to customize how the Package Manager selects indirect dependencies based on Semantic Versioning rules by setting the resolutionStrategy property:
Value: | Description: |
|---|---|
| lowest | Do not upgrade indirect dependencies. Instead, it uses exactly the requested version. This is the default mode. |
| highestPatch | Upgrade to the highest version with the same Major and Minor components. For example, with the requested version 1.2.3, this strategy selects the highest version in the range |
| highestMinor | Upgrade to the highest version with the same Major component. For example, with the requested version 1.2.3, this strategy selects the highest version in the range Note: Version |
| highest | Upgrade to the highest version. For example, with the requested version 1.2.3, this strategy selects the highest version in the range |
注意
These ranges never allow a dependency to jump from a stable release to an experimental or pre-release package.