Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression: Pinning dependencies behaves differently than npm. #3775

Closed
jgerigmeyer opened this issue Jun 30, 2017 · 3 comments
Closed

Regression: Pinning dependencies behaves differently than npm. #3775

jgerigmeyer opened this issue Jun 30, 2017 · 3 comments

Comments

@jgerigmeyer
Copy link

jgerigmeyer commented Jun 30, 2017

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 left-pad@1.1.1 and color-parse@1.2.0, which itself depends on left-pad@^1.1.1:

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

npm@5.0.4 and yarn@0.24.6 both use the pinned version left-pad@1.1.1, whereas yarn@0.27.3 installs the latest left-pad@1.1.3 for color-parse, and leaves the pinned version left-pad@1.1.1 in the root.

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

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

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
Copy link
Member

arcanis commented Jun 30, 2017

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
Copy link
Author

@arcanis That RFC would certainly work for me! 👍

@bestander
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants