Yarn upgrade creates duplicate dependency resolution

[xdumaine]

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

What is the current behavior?

I have a dependency tree like this

app
|-- shared-dep@^1.0.0
|-- dep-1
|   |-- shared-dep@^1.1.0
|-- dep-2
     |-- shared-dep@^1.1.0

And when I yarn upgrade shared-dep (say when 1.2.0 is released) it causes duplication in yarn.lock where the resolution for shared-dep doesn't change for the version pulled in by dep-1 and dep-2 and it adds a new (duplicate) resolution for shared-dep so that now it's pulling in 1.1.0 and 1.2.0.

Before upgrade:

"shared-dep@^1.1.0", "shared-dep@1.0.0":
  version: "1.1.0"
  resolved "..."

After upgrade:

"shared-dep@^1.1.0", "shared-dep@1.0.0":
  version: "1.1.0"
  resolved "..."

"shared-dep@^1.2.0":
  version: "1.2.0"
  resolved "..."

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

1. Clone https://github.com/xdumaine/yarn-issue-3967
2. Run yarn upgrade commander@^2.4.0
3. Observe that the new yarn.lock file has two overlapping entries for commander:

   commander@^2.3.0:
     version "2.3.0"
     resolved "https://registry.yarnpkg.com/commander/-/commander-.3.0.tgz#fd430e889832ec353b9acd1de217c11cb3eef873"
   
   commander@^2.4.0:
     version "2.11.0"
     resolved "https://registry.yarnpkg.com/commander/-/commander-2.11.0.tgz#157152fd1e7a6c8d98a5b715cf376df928004563"
   

What is the expected behavior?

Having a single commander entry in the lockfile:

commander@^2.3.0, commander@^2.4.0:
  version "2.11.0"
  resolved "https://registry.yarnpkg.com/commander/-/commander-2.11.0.tgz#157152fd1e7a6c8d98a5b715cf376df928004563"

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

OS X 10.12.5
node v8.9.0
yarn v1.3.2

[BYK]

Hi @xdumaine, thanks for creating a separate issue for this!

Would you mind providing us an isolated, reliable reproduction script so we can test this quickly? Even a very simple package.json file that demonstrates the issue with yarn install would be enough.

Thanks!

[xdumaine]

@BYK This repo has a package.json and yarn.lock which will reproduce it. Just check it out, and run yarn upgrade commander

https://github.com/xdumaine/yarn-issue-3967

[xdumaine]

Note that the results for removing yarn.lock and running yarn install are different from running yarn upgrade when the yarn.lock already exists. Herein lies the bug.

[OliverJAsh]

I can confirm the behaviour described by @xdumaine still occurs on Yarn v1.0.2.

The only workarounds I know of are:

• Manually dedupe by updating lockfile by hand
• Uninstall and then reinstall all dependencies using the shared dependency

[xdumaine]

@BYK can you please update the labels on this so that it will maybe get fixed?

[BYK]

@xdumaine I didn't have time to look into this more yet. Will update the labels once I confirm and know where to look.

[danez]

The current workaround we do is deleting node_modules and yarn.lock and running yarn again.

[voxpelli]

I recently experienced this same behavior with Yarn 1.1.0 in a project and the workaround of deleting node_modules and yarn.lock and running yarn install again solved it for me.

I can't however reproduce the issue by running yarn upgrade commander on https://github.com/xdumaine/yarn-issue-3967 – a simple yarn install even changes the yarn.lock in that repo.

The issue seems to be one of a faulty deduplication – where running a yarn upgrade doesn't properly dedupe subdependencies (and where running it repeatedly doesn't help either).

[xdumaine]

@voxpelli run yarn upgrade commander@^2.11.0 to see the problem.

It's currently still reproducible on yarn 1.1.0 if you do a targeted version upgrade that matches the current package.json range. So yarn upgrade commander in the example repo will not reproduce it, but yarn upgrade commander@^2.4.0 will still reproduce it.

[voxpelli]

I can confirm that yarn upgrade commander@^2.11.0 reproduced the outlined behavior.

Though core issue was about yarn upgrade? Is the expectation that same deduplication should happen when upgrading individual dependencies as when upgrading all dependencies?

Because issue with just yarn upgrade I can't reproduce there.

[xdumaine]

The issue was around upgrading a specific package yarn upgrade shared-dep and still applies. It still requires manual modification of the yarn lockfile every time this happens. I'd really love for the needs-repro-script tag to be removed, because this has a repro script, and can be reproduced every time. @BYK @voxpelli