Handling dependencies of dependencies and their resolution

[victornoel]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

This has been made visible via angular/angular-cli#4611 and angular/angular-cli#4787.

Basically, there are some dependencies to:

• "@angular/cli": "1.0.0-beta.32.3" (as a devDependencies)
  • which depends on "@angular/compiler" ">=2.3.1 <5.0.0"
• "@angular/compiler": "4.0.0-beta.8" (as a dependencies)

The problem is that yarn resolves @angular/cli dependency to "@angular/compiler" "2.4.8" which creates problems with angular-cli.

If the current behavior is a bug, please provide the steps to reproduce.

See angular/angular-cli#4787 (comment):

sudo yarn global add @angular/cli
ng set --global packageManager=yarn
ng new MyYarnApp -ng4
cd MyYarnApp
ng serve or ng build

What is the expected behavior?

I would either expect yarn to:

• consider that since "@angular/compiler": "4.0.0-beta.8" is explicitly expressed in the package.json, it should use it also for dependencies dependencies if it matches (which is the case here).
• at least give me a way to force dependencies dependencies versions if I need to.

Please mention your node.js, yarn and operating system version.

yarn 0.20.3, node 6.10.0, latest archlinux

[victornoel]

For the record, I tried to use the resolutions field to force the version of the concerned dependencies, but they are just ignored…

[kylecordes]

It is possible to work around this by running yarn, manually editing yarn.lock, deleting node modules, and rerunning yarn. Not fun.

[coryrylan]

Was able to get this running with what @kylecordes said as well

[moimikey]

i've dealt with this too unfortunately. my solution has been to simply regenerate the lock file :/, even if it means rm'ing it and regenerating it. i install my dependencies flat, so during the "choose version" question and answer game, if I accidentally select the wrongly resolved semver, i'm stuck in that choice and need to rebuild yarn.lock again to get the correct version resolved.

[maxime1992]

@moimikey erasing the yarn.lock is not an option here (for those who don't use flat). Indeed, upgrading to angular v4 while angular-cli still have a dep on angular v2 give something like that in yarn.lock :

"@angular/core@4.0.0-rc.1", "@angular/core@>=2.3.1 <5.0.0 || >=4.0.0-beta <5.0.0":
  version "4.0.0-rc.1"
  resolved "https://registry.yarnpkg.com/@angular/core/-/core-4.0.0-rc.1.tgz#7f87b7696b407476e45d6d3c1880a50d5afbb6e3"

"@angular/core@^2.0.0":
  version "2.4.8"
  resolved "https://registry.yarnpkg.com/@angular/core/-/core-2.4.8.tgz#bf1a4fc324827516e6c3222047a9b2cbdaee6976"

So we have to change it by hand to

"@angular/core@4.0.0-rc.1", "@angular/core@>=2.3.1 <5.0.0 || >=4.0.0-beta <5.0.0", "@angular/core@^2.0.0":
  version "4.0.0-rc.1"
  resolved "https://registry.yarnpkg.com/@angular/core/-/core-4.0.0-rc.1.tgz#7f87b7696b407476e45d6d3c1880a50d5afbb6e3"

[mattma]

@maxime1992 @splintercode the issue has been fixed and works as expected

[victornoel]

@mattma no it wasn't, or at least not the problem underlined here in this issue, see my comment on the angular-cli thread.

But after some thought, I'm not sure it make really sense to consider this situation a "bug"... anyway I will leave this decision to yarn dev.
Though I think that the resolve property of package.json should have helped with the situation, which isn't the case, so this can be called a "bug" :)

[mattma]

@victornoel thanks for the updates. I agree with you.

[cansin]

@mattma is there a separate issue open for "resolutions bug" that I could subscribe to? I searched through the list but couldn't find any. Perhaps this is the right one to subscribe to? Thank you!

[cansin]

Shoot. I meant to ask above question to @victornoel ^^

[victornoel]

@cansin sorry, I saw it, but anyway I'm not sure how to answer that… what's your objective here? You just want to know about "resolutions bug" in general?

[cansin]

@victornoel I have a package.json where I try to fixate certain library versions e.g.

  "dependencies": {
    "jquery": "1.11.3",
     ... and some other dependencies
  },
  "resolutions": {
    "jquery": "1.11.3",
  },

But I still end up with a yarn.lock file that has multiple entries for jquery package. I was under the impression adding a resolution for a package would result in:

1. Either raise an error when resolution cannot be met,
2. Or fix the jquery version to 1.11.3 no matter what.

But in my case yarn silently ignores the resolution and decides to resolve a sub jquery dependency with a concrete jquery@2.2.4.

[cansin]

Wait for a second, I was right about asking the question to @mattma in the first place. As they claimed the issue is fixed, and not you @victornoel . Sorry about the confusion.

Anyway @mattma care to comment re: above?

[maxime1992]

@cansin a simple fix is to edit yarn.lock while this issue is still open.

For example, in my project I use Typescript (v2.3.1) but sub dependencies relies on others Typescript versions. No matter what I try to do in package.json, my yarn.lock always ends up into something like that :

...

typescript@2.3.1:
  version "2.3.1"
  resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.3.1.tgz#e3361fb395c6c3f9c69faeeabc9503f8bdecaea1"

"typescript@>=2.0.0 <2.3.0":
  version "2.2.2"
  resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.2.2.tgz#606022508479b55ffa368b58fee963a03dfd7b0c"

...

I just edit it by hand like that :

...

typescript@2.3.1, "typescript@>=2.0.0 <2.3.0":
  version "2.3.1"
  resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.3.1.tgz#e3361fb395c6c3f9c69faeeabc9503f8bdecaea1"

...

So yes, it ain't perfect solution to edit yarn.lock by hand but it's working for now 😉