This is an example case showing that a
yarn.lock file does not guarantee
package resolutions at all levels.
root (email@example.com, firstname.lastname@example.org, email@example.com) <-- 1.x dep here +-- x 1.2.0 <-- 1.x resolves to 1.2.0 +-- y (firstname.lastname@example.org, email@example.com) | +-- x 1.1.0 <-- 1.x resolves to 1.1.0 | +-- z 2.0.0 (firstname.lastname@example.org) <-- 1.x dep here +-- z 1.0.0
Both Yarn and npm create the same folder structure in
is good. But the
yarn.lock file indicates that
email@example.com should resolve to
firstname.lastname@example.org's dependency on
email@example.com resolves to
yarn.lock on its own does not guarantee resolutions or
deterministic builds. That part of the contract is provided by the
implementation of Yarn itself, not in the lockfile format.