If the root package (incorrectly, as it’s an unlisted dep) does require("baz"), the result would not be guaranteed by the yarn.lock file. +- yarn.lock file can’t tell you which one to use. But that (at least, in itself) is not equivalent to guaranteeing a deterministic tree shape!Ĭonsider this dependency graph: root -> -> -> of these package trees would be just as correct as the other: root For example, if resolves to it’ll continue to resolve to that version number in subsequent installs for all Yarn versions, given a consistent yarn.lock file. It is possible that a different version of Yarn will result in a different tree layout on disk.Ī yarn.lock file does guarantee deterministic resolutions of dependencies. Yarn installs are guaranteed to be deterministic given a single combination of yarn.lock and Yarn version. So if it’s good enough for Yarn, why doesn’t npm just use that? Deterministic Build Results Npm will still create a package-lock.json file, and if a package-lock.json file is present, it’ll be used as the authoritative definition of the tree shape to create. If packages are added or removed, then the yarn.lock file will be updated. The resolved values will tell it where to fetch packages from, and the integrity will be used to check that the result matches expectations.
In npm v7, if a yarn.lock file exists, npm will use the metadata it contains. If multiple packages depend on they’ll all get the same resolution. This says “Any dependency on should resolve to this exact thing”. Integrity sha512-N2REVrJ/X/jGPfit2d7zea2J1pf7EAR5chIUcfHffAZ7gmlam5U65sAm76+o4ntQbSRdTjYf7qZz3chuHlwXEA= Basic Structure of a yarn.lock FileĪ yarn.lock file is a map of requested dependency specifiers to metadata describing their resolution. The simple answer is: because yarn.lock doesn’t fully address npm’s needs, and relying on it exclusively would limit our ability to produce optimal package installs or add features in the future. One common question we’ve gotten a few times now, once we announce that npm v7 will include support for yarn.lock files, is “Why keep package-lock.json at all, then? Why not just use yarn.lock only?”
#Archiver npm series#
Npm v7 Series - Why Keep `package-lock.json`? Updates from the npm team are now published on the
0 kommentar(er)
