The Design Space of Lockfiles Across Package Managers

TL;DR

This paper presents the first cross-ecosystem study of lockfiles across seven package managers (npm, pnpm, Cargo, Poetry, Pipenv, Gradle, Go), combining code/documentation analysis with qualitative interviews of 15 developers. It characterizes lockfile content and lifecycle, showing substantial differences in what is stored (e.g., checksums, indirect dependencies) and how updates and enforcement are handled. The authors quantify lockfile adoption in public GitHub projects, revealing Go’s near-universal practice and Gradle’s scarcity, while other ecosystems show mixed but growing adoption. Through developer interviews, the study identifies five benefits (determinism, integrity, transparency, debugging, security) and five challenges (readability, indirect locking, update delays, caching, learning curve), and offers actionable recommendations for users and tool developers to improve lockfile usability and adoption. Overall, the work highlights principled lockfile design as a lever for reproducible, secure, and efficient dependency management across programming ecosystems.

Abstract

Software developers reuse third-party packages that are hosted in package registries. At build time, a package manager resolves and fetches the direct and indirect dependencies of a project. Most package managers also generate a lockfile, which records the exact set of resolved dependency versions. Lockfiles are used to reduce build times; to verify the integrity of resolved packages; and to support build reproducibility across environments and time. Despite these beneficial features, developers often struggle with their maintenance, usage, and interpretation. In this study, we unveil the major challenges related to lockfiles, such that future researchers and engineers can address them. We perform the first comprehensive study of lockfiles across 7 popular package managers, npm, pnpm, Cargo, Poetry, Pipenv, Gradle, and Go. First, we highlight the wide variety of design decisions that package managers make, regarding the generation process as well as the content of lockfiles. Next, we conduct a qualitative analysis based on semi-structured interviews with 15 developers. We capture first-hand insights about the benefits that developers perceive in lockfiles, as well as the challenges they face to manage these files. Following these observations, we make 5 recommendations to further improve lockfiles, for a better developer experience.

Figures (2)

• Figure 1: A canonical workflow of interactions between a developer, the dependency specification file, the package manager, the lockfile, and the package registry. The order of events may slightly vary depending on the exact command executed by the developer in step 2.
• Figure 2: Example dependency representations extracted from lockfiles (or a mod file) across seven package managers. Each listing contains one extracted record corresponding to a direct dependency in a lockfile. Dependency versions are highlighted in yellow, source links in blue, checksums in green, and indirect dependencies in pink. Some details are omitted for brevity and clarity.

Theorems & Definitions (4)

• Definition 1
• Definition 2
• Definition 3
• Definition 4