Regression: Pinning dependencies behaves differently than npm.

[jgerigmeyer]

Do you want to request a feature or report a bug?
Bug (regression)

What is the current behavior?
This is a regression of #681: "Pinning a package to an exact version in package.json does not also pin it for dependencies, even if the pinned version satisfied the range."

If the current behavior is a bug, please provide the steps to reproduce.
I've pinned [email protected] and [email protected], which itself depends on left-pad@^1.1.1:

"dependencies": {
  "color-parse": "1.2.0",
  "left-pad": "1.1.1"
}

[email protected] and [email protected] both use the pinned version [email protected], whereas [email protected] installs the latest [email protected] for color-parse, and leaves the pinned version [email protected] in the root.

npm v5.0.4:

├─┬ [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ └── [email protected] deduped
└── [email protected]

yarn v0.24.6:

├─ [email protected]
├─ [email protected]
│  ├─ color-name@^1.0.0
│  ├─ is-plain-obj@^1.1.0
│  └─ left-pad@^1.1.1
├─ [email protected]
└─ [email protected]

yarn v0.27.3:

├─ [email protected]
├─ [email protected]
│  ├─ color-name@^1.0.0
│  ├─ is-plain-obj@^1.1.0
│  ├─ left-pad@^1.1.1
│  └─ [email protected]
├─ [email protected]
└─ [email protected]

What is the expected behavior?
As stated in #681: "I would expect that because a stricter definition of a root-level dependency satisfies the sub-dependency's version, it is used instead."

Please mention your node.js, yarn and operating system version.
Node 6.10.3, OSX 10.12.5, yarn 0.27.3

[arcanis]

I'm not sure Yarn should make any guarantee regarding the layout of the dependencies (except that any installed dependency satisfies the dependency specified inside its parent package.json), since that would prevent us from improving the package tree resolution later (for example the issue you've noticed is caused by a fix that actually makes Yarn give more stable when generating the disk tree).

I think the best way to solve your use case lies in the following RFC (not yet merged nor implemented), that specifies how to explicitely override sub-dependency versions: yarnpkg/rfcs#68

What do you think?

[jgerigmeyer]

@arcanis That RFC would certainly work for me! 👍

[bestander]

I agree with @arcanis that Yarn should not give guarantees because this depends on the order when dependencies are resolved.
Let's defer to that RFC 68.
Later on we should improve how Yarn optimizes the resolution tree