A lock file contains the results of the Package Manager’s dependency resolution for a project. Package managers use lock files to provide a deterministic result when resolving a package dependency graph. When the Unity Package Manager computes a successful resolution, it stores that resolution inside the project’s Packages folder in a JSON file called packages-lock.json. Any modification to the project manifestEach Unity project has a project manifest, which acts as an entry point for the Package Manager. This file must be available in the <project>/Packages directory. The Package Manager uses it to configure many things, including a list of dependencies for that project, as well as any package repository to query for packages. More info
See in Glossary or to a mutableYou can change the contents of a mutable package. This is the opposite of immutable. Only Local packages and Embedded packages are mutable.
See in Glossary package’s manifest (either embedded or installed from local folder) can potentially compel the Package Manager to recalculate the resolved package versions. But as long as the version of a package in the lock file satisfies the range implied by the dependencyIn the context of the Package Manager, a dependency is a specific package version (expressed in the form package_name@package_version) that a project or another package requires in order to work. Projects and packages use the dependencies attribute in their manifests to define the set of packages they require. For projects, these are considered direct dependencies; for packages, these are indirect, or transitive, dependencies. More info
See in Glossary version and the resolution strategy, the package remains locked at that version.
For example, here is a typical entry in the lock file:
"com.unity.textmeshpro": {
"version": "2.0.1",
"depth": 0,
"source": "registry",
"dependencies": {
"com.unity.ugui": "1.0.0"
},
"url": "https://packages.unity.com"
},
etc.
When the Package Manager resolves any conflicting indirect dependencies, it tries to re-use as many locked packages as possible. This guarantees that subsequent dependency resolution produces the same results for the same set of dependencies. It also minimizes time-consuming operations such as downloading, extracting, or copying packages.
If there is no solution that only includes locked packages, then the Package Manager chooses the set of packages with the least risky upgrades, preferring patch upgrades over minor or major upgrades, and minor upgrades over major upgrades. In fact, you can customize the level of risk for upgrading. For more information, see Customizing resolution strategies.
To force a refresh of indirect dependency versions, delete the lock file.
Don’t manually modify the lock file: the Package Manager creates and maintains the lock file, so it overwrites any changes you make to the file.
Put the lock file under source control so you can consistently reproduce the same package set to ensure your project remains consistent over time and on different machines.
By default, the Package Manager creates or updates the lock file when it successfully computes a dependency graph. If you see unexpected results, you can set the enableLockFile property to false in your project manifest to disable locking. However, if you disable the lock file, the Package Manager clones Git URL packages again, which leads to reduced performance and additional network usage. It might also lead to non-deterministic results if you push newer commits to the remote Git repository between two resolutions.