R Npm Download In The
It is possible that a different version of Yarn will result in a different tree layout on disk.A yarn.lock file does guarantee deterministic resolutions of dependencies. If packages are added or removed, then the yarn.lock file will be updated.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.So if it’s good enough for Yarn, why doesn’t npm just use that? Deterministic Build ResultsYarn installs are guaranteed to be deterministic given a single combination of yarn.lock and Yarn version. The resolved values will tell it where to fetch packages from, and the integrity will be used to check that the result matches expectations. If multiple packages depend on they’ll all get the same resolution.In npm v7, if a yarn.lock file exists, npm will use the metadata it contains. For example: "1.0.2"Integrity sha512-N2REVrJ/X/jGPfit2d7zea2J1pf7EAR5chIUcfHffAZ7gmlam5U65sAm76+o4ntQbSRdTjYf7qZz3chuHlwXEA=This says “Any dependency on should resolve to this exact thing”. Basic Structure of a yarn.lock FileA yarn.lock file is a map of requested dependency specifiers to metadata describing their resolution.
The npm tree building contract is entirely specified by the package-lock.json file. To its credit, Yarn is smart enough to not be subject to discrepancies in package manifest load times when building the tree, or else determinism would not be guaranteed.As this is defined by the particulars of Yarn’s algorithm rather than by the data structure on disk (which does not identify the algorithm to be used), that determinism guarantee is fundamentally weaker than what a package-lock.json provides by fully specifying the shape of the package tree on disk.In other words, the Yarn tree building contract is split between the yarn.lock file and the implementation of Yarn itself. Code doesn’t change unless someone changes it. This is a form of determinism that the package-lock.json file can provide, and a yarn.lock file cannot.In practice, of course, since Yarn has all the required information in the yarn.lock file to make this choice, it is deterministic as long as everyone is using the same version of Yarn, so that the choice is being made in exactly the same way. 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. But that (at least, in itself) is not equivalent to guaranteeing a deterministic tree shape!Consider this dependency graph: root -> -> -> of these package trees would be just as correct as the other: root+- yarn.lock file can’t tell you which one to use.
So, following the Yarn algorithm exactly isn’t ideal in these cases.Consider this dependency graph: root -> -> -> -> -> -> root project depends on version 1.x of x, y, and z. While npm uses the yarn.lock file as a reliable source of information, it does not treat it as an authoritative set of constraints.In some cases Yarn produces a tree with excessive duplication, which we don’t want to do. Nesting and DeduplicationFurthermore, there is a class of nesting and deduplication cases where the yarn.lock file does not accurately reflect the resolutions that will be used by npm in practice, even when npm does use it as a source of metadata.
0 kommentar(er)
