Pinning dependencies behaves differently than npm.

[STRML]

Do you want to request a feature or report a bug?
Bug, or at least a behavior deviation.

What is the current behavior?
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 created a reproduction repository here.

In short, I've pinned left-pad to 1.1.1 at the root, which satisfies color-parse's dependency of "left-pad": "^1.1.1". However, yarn gives 1.1.3 to color-parse, and 1.1.1 to the root. npm just uses 1.1.1 for both.

Note the differences in the npm & yarn tree:

npm 3.10.3

├─┬ color-parse@1.2.0
│ ├── color-name@1.1.1
│ └── is-plain-obj@1.1.0
└── left-pad@1.1.1

yarn

yarn ls v0.15.1
├─ color-name@1.1.1
├─ color-parse@1.2.0
│  ├─ color-name@^1.0.0
│  ├─ is-plain-obj@^1.1.0
│  ├─ left-pad@^1.1.1
│  └─ left-pad@1.1.3
├─ is-plain-obj@1.1.0
└─ left-pad@1.1.1

What is the expected behavior?
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.7.0, OSX 10.11, yarn 0.15.1 & npm 3.10.3.

This can be fixed by editing the yarn.lock directly but this could be error-prone.

[kanongil]

Note that a manual edit to the yarn.lock file doesn't work once you distribute your package.

[STRML]

Perhaps the right solution is a yarn.override file that is considered in generation of yarn.lock? Something we can check in and version separately to pin dependencies of dependencies? This is a major change could help with this problem regarding pinning multiple subdependencies.

[kanongil]

This issue also seems related to #579 & #901.

[markstos]

Something like yarn.override would be very appealing to me. Consider a module that has an insecure dependency that needs updated ASAP, before the module maintainer gets to it. An edit the yarn.lock could get lost during re-generation and adding a new dependency to package.json is not ideal for something that's not a top level dependency. An "override" file clearly expresses that certain dependencies are meant to override the dependencies that would normally be resolved.

[arcanis]

This issue seems to be fixed. Let me know if it's not.

❯ [mael-mbp?] /Users/mael/test ❯ yarn list

Using globally installed version of Yarn
yarn list v0.23.2
warning No license field
├─ color-name@1.1.2
├─ color-parse@1.3.2
│  ├─ color-name@^1.0.0
│  └─ is-plain-obj@^1.1.0
├─ is-plain-obj@1.1.0
└─ left-pad@1.1.1
✨  Done in 0.10s.

[jgerigmeyer]

This issue was fixed, but now I'm seeing it again with v0.27.3. (It was working in v0.24.6.)

package.json:

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

yarn v0.24.6:

├─ color-name@1.1.2
├─ color-parse@1.2.0
│  ├─ color-name@^1.0.0
│  ├─ is-plain-obj@^1.1.0
│  └─ left-pad@^1.1.1
├─ is-plain-obj@1.1.0
└─ left-pad@1.1.1

yarn v0.27.3:

├─ color-name@1.1.2
├─ color-parse@1.2.0
│  ├─ color-name@^1.0.0
│  ├─ is-plain-obj@^1.1.0
│  ├─ left-pad@^1.1.1
│  └─ left-pad@1.1.3
├─ is-plain-obj@1.1.0
└─ left-pad@1.1.1

npm v5.0.4:

├─┬ color-parse@1.2.0
│ ├── color-name@1.1.2
│ ├── is-plain-obj@1.1.0
│ └── left-pad@1.1.1 deduped
└── left-pad@1.1.1