Software projects often depend on libraries maintained and released independently. A dependency manifest records which packages the project requires and which version ranges are acceptable.

A range such as “any compatible 2.x release” describes policy, but resolving it at different times can select different concrete versions.

A lockfile records the exact resolved dependency graph used for a build. Committing that resolution lets developers and automated systems start from the same package versions instead of silently receiving whatever happens to be newest.

Dependencies can themselves depend on other packages, creating transitive dependencies. Updating one direct dependency may therefore change more of the resolved graph than the top-level manifest suggests.

Dependency updates should be explicit changes: resolve a new graph, review what changed, run the project's verification and then commit the new resolution.

A lockfile does not guarantee that dependencies are correct or trustworthy. It makes the selected dependency set reproducible and reviewable.