Yarn: Yarn resolves package wrong

[BorntraegerMarc]

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

Bug
What is the current behavior?
Check out my comment at https://github.com/angular/angular-cli/issues/7113#issuecomment-317715412

With the posted package.json yarn installs the wrong dependencies with version v0.27.5 doesn't resolve dependencies properly while v0.24.6 does.

The problem is the enhanced-resolve dependency.

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

Copy the package.json from Check out my comment at https://github.com/angular/angular-cli/issues/7113#issuecomment-317715412

it resolves to

enhanced-resolve@^3.0.0:   version "3.4.1"   resolved "https://registry.yarnpkg.com/enhanced-resolve/-/enhanced-resolve-3.4.1.tgz#0421e339fd71419b3da13d129b3979040230476e"   dependencies:     graceful-fs "^4.1.2"     memory-fs "^0.4.0"     object-assign "^4.0.1"     tapable "^0.2.7"
--

What is the expected behavior?
It should resolve correctly.

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

node -v
v6.9.1

yarn -v
v0.27.5

Windows 10

[andreasonny83]

In my understanding, enhanced-resolve has been correctly resolved to the latest minor version.
3.4.1 is compatible with ^3.0.0. The ^ will upgrade all the minors and patches version and will exclude any upgrade to version >= 4.0.0. If you want Yarn or npm, not to upgrade to any major or minor release, you should use the tilde syntax instead: enhanced-resolve: "~3.0.0".

I really think the problem is with Webpack that should use enhanced-resolve: "3.3.0" in their package.json instead of enhanced-resolve: "^3.0.0"

[BorntraegerMarc]

But I'm not even using webpack. So the dependency come from @ngtools/webpack? How I see it, they also have pinned down the version: https://github.com/angular/angular-cli/blob/v1.2.4/packages/%40ngtools/webpack/package.json#L28

[BorntraegerMarc]

Ah I see @andreasonny83 you meant this line: https://github.com/webpack/webpack/blob/master/package.json#L12 isn't there an option to pin down

[BorntraegerMarc]

In this case is there really nothing that can be done to get yarn to work?

[andreasonny83]

@BorntraegerMarc , if you're using @ngtools/webpack, make sure to use the latest version as they just released a quick-fix for that issue yesterday.

Your package.json should mention: "@ngtools/webpack": "^1.5.3"

[BorntraegerMarc]

I'm not using @ngtools/webpack. Adding it to my package.json also didn't help...

[BorntraegerMarc]

@andreasonny83

yarn list enhanced-resolve
yarn list v0.27.5
├─ @angular/[email protected]
│  └─ [email protected]
├─ [email protected]
└─ [email protected]
   └─ [email protected]
Done in 1.31s.

although it's specified here directly: https://github.com/angular/angular-cli/blob/v1.2.4/package.json#L54

Plus the build works if you downgrade to v0.24.6. So maybe it's a yarn problem after all?

[BYK]

@BorntraegerMarc can you please provide us with a minimal reproducible case so we can see if this is a yarn issue or not? A minimal case would be providing a package.json file with the minimum possible dependencies in it to demonstrate the issue and a clear explanation of what is expected and what is happening.

Until then we cannot really help :(

[BorntraegerMarc]

Sure @BYK here is the package.json:

{
    "dependencies": {
    },
    "devDependencies": {
        "@angular/cli": "1.2.4",
        "enhanced-resolve": "3.3.0"
    }
}

This is the output on console:

D:\projects\komed-health-web> yarn --version
0.27.5
D:\projects\komed-health-web> yarn
yarn install v0.27.5
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
warning [email protected]: The platform "win32" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 21.88s.

In the yarn.lock file I see:

[email protected]:
  version "3.3.0"
  resolved "https://registry.yarnpkg.com/enhanced-resolve/-/enhanced-resolve-3.3.0.tgz#950964ecc7f0332a42321b673b38dc8ff15535b3"
  dependencies:
    graceful-fs "^4.1.2"
    memory-fs "^0.4.0"
    object-assign "^4.0.1"
    tapable "^0.2.5"

enhanced-resolve@^3.0.0:
  version "3.4.1"
  resolved "https://registry.yarnpkg.com/enhanced-resolve/-/enhanced-resolve-3.4.1.tgz#0421e339fd71419b3da13d129b3979040230476e"
  dependencies:
    graceful-fs "^4.1.2"
    memory-fs "^0.4.0"
    object-assign "^4.0.1"
    tapable "^0.2.7"

then the older yarn version:

D:\projects\komed-health-web> yarn --version
0.24.6
D:\projects\komed-health-web> yarn
yarn install v0.24.6
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
warning [email protected]: The platform "win32" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 5.46s.

And I see only this in the lock file:

[email protected], enhanced-resolve@^3.0.0:
  version "3.3.0"
  resolved "https://registry.yarnpkg.com/enhanced-resolve/-/enhanced-resolve-3.3.0.tgz#950964ecc7f0332a42321b673b38dc8ff15535b3"
  dependencies:
    graceful-fs "^4.1.2"
    memory-fs "^0.4.0"
    object-assign "^4.0.1"
    tapable "^0.2.5"

[BorntraegerMarc]

PS: I always deleted the lock file. Just to be sure.
So having both version 3.3.0 and 3.4.1 of enhanced-resolve in the project is causing this angular error angular: https://github.com/angular/angular-cli/issues/7113 which doesn't really need to concern yarn. But I'm just not sure if this is a bug from yarn version 0.24.6 or 0.27.5. But in my view all versions should resolve the same libraries....

[BYK]

@BorntraegerMarc - This seems like expected behavior to me. Your system seems to be relying on hoisting specifics instead of declaring its dependencies properly via peerDependencies, hence it breaks when the hoisting algorithm changes and does something different now.

See the discussion on #3951 please.

I did some debugging and looks like webpack defines enhanced-resolve as a dependency and the ^3.0.0 range comes from there. Your projects define the same package as a dependency but specifically at version 3.3.0. There's no guarantee that your packages and webpack would share the same dependency. If that's what you want, then you should list enhanced-resolve as a peer dependency for both. @arcanis correct me if I'm wrong here please.

[BorntraegerMarc]

@BYK it is expected behavior that v0.24.6 and v0.27.5 resolve dependencies totally different?

[basvandenberg]

After I upgraded my angular-cli I had the same issue, the production build didn't work. The proposed solution was 'fixing' the enhanced-resolve to version 3.3.0 with:

npm install --dev [email protected]

Since I use yarn, I tried to do the same with:

yarn add --dev [email protected]

This did not solve the issue when using yarn 0.27.5, but it did after I downgraded to yarn 0.24.6. So yarn v0.27.5 seems to behave different compared to npm and yarn v0.24.6.

[BYK]

@BYK it is expected behavior that v0.24.6 and v0.27.5 resolve dependencies totally different?

Yes. Yarn guarantees consistency for only the same major version of yarn with the same lock file. With the upcoming Yarn 1.0, this will be clearer hopefully since when doing 0.x releases, each release is a major release. See https://yarnpkg.com/blog/2017/05/31/determinism/

In practice this means that the position of packages in node_modules is computed internally in Yarn, which causes Yarn to be non-deterministic between people using different versions.

Even though Yarn hoisting may differ between versions we still make very strong guarantees around hoisting when the same version of Yarn is used. The most significant of these guarantees is that omitting environmental dependencies like optionalDependencies and devDependencies still influences the position of normal dependencies.

npm 5 has stronger guarantees across versions and has a stronger deterministic lockfile, but Yarn only has those guarantees when you’re on the same version in favor of a lighter lockfile that is better for review.

Long story short, this is expected. If you can provide more details about which package needs what other package and who relies on them being the same version, I can possibly provide a solution or may uncover a bug. Since I still don't fully understand what is the expected dependency tree and how it is defined here I cannot confidently say this is a bug or not yet.

[BorntraegerMarc]

Alright, didn't know yarn guarantees consistency for only the same major version. This issue can be closed in that case. Sorry, I don't have the time in the moment to make any further investigations...

Thx!

[BYK]

@BorntraegerMarc alright then. Sorry for the inconvenience!

Please come back if you have any findings that may point the arrows to yarn. My suspicion is, someone needing to list [email protected] in their peerDependencies though :)