This is an example case showing that a yarn.lock file does not guarantee
package resolutions at all levels.
root (x@1.x, y@1.x, z@1.x) <-- 1.x dep here
+-- x 1.2.0 <-- 1.x resolves to 1.2.0
+-- y (x@1.1, z@2.x)
| +-- x 1.1.0 <-- 1.x resolves to 1.1.0
| +-- z 2.0.0 (x@1.x) <-- 1.x dep here
+-- z 1.0.0
Both Yarn and npm create the same folder structure in node_modules, which
is good. But the yarn.lock file indicates that x@1.x should resolve to
version 1.2.0, and z@2.0.0's dependency on x@1.x resolves to 1.1.0
instead.
Conclusion: 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.