Renovate: when updating any dependency, update deeply

Created on 2 Dec 2018 · 16Comments · Source: renovatebot/renovate

What would you like Renovate to be able to do?

We never want more than one version of a dependency in the web bundle.

If my project depends on a dependency, say @types/[email protected], and my project also depends on a project @types/react-dom that depends on @types/react@*, the lockfile will have something this:

"@types/react@*", "@types/[email protected]":
  version "16.7.10"

When Renovate creates a PR to upgrade _my_ @types/react dependency to 16.7.11, it doesn't automatically also upgrade the reference from @types/react-dom, so we get this in our lockfile:

"@types/react@*":
  version "16.7.10"

"@types/[email protected]":
  version "16.7.11"

While two versions of types shouldn't matter, I think they both declare some global stuff which makes Typescript mad because I have two versions of React in the same project.

Worse is any JS that goes in a web bundle. Having multiple versions of the same dependency means two versions of the same library to the web bundle, causing unexpected bundle size increases.

The weekly lockfile updates also leads this problem because it's updating transient (might be wrong word) dependencies in the lockfile but not the matching ones in my package.json files:

"@types/react@*":
  version "16.7.12"

"@types/[email protected]":
  version "16.7.11"

Describe the solution you'd like

When upgrading any dependency, _all_ valid matching uses of that dependency should be upgraded simultaneously.

Basically deep upgrade, not shallow upgrade, for any particular dependency.

Describe alternatives you've considered

Right now I need to do this manually to a PR at least once a week.

Additional context

self-hosted 13.136.6

npm priority-3-normal feature

Source

dylang

👍2

Most helpful comment

@dylang can you confirm if yarn-deduplicate achieves what you want? If so the we could perhaps add it as an opt-in option to run it against the updated yarn.lock.

rarkins on 5 Dec 2018

🎉2 👍1

All 16 comments

Right now we rely on npm and yarn binaries to do lockfile updates, but maybe there’s something we can do to force a more optimised calculation. By default I think they try to impact as little of the lockfile as possible.

rarkins on 2 Dec 2018

Can you provide an example package file /lockfile to reproduce? I can then experiment with various approaches.

rarkins on 2 Dec 2018

for yarn.lock, https://www.npmjs.com/package/yarn-deduplicate does that

christophehurpeau on 5 Dec 2018

@dylang can you confirm if yarn-deduplicate achieves what you want? If so the we could perhaps add it as an opt-in option to run it against the updated yarn.lock.

rarkins on 5 Dec 2018

🎉2 👍1

@christophehurpeau thanks for your sign-up today as well as suggestion!

rarkins on 5 Dec 2018

🎉1

@dylang please confirm ?

christophehurpeau on 13 Dec 2018

oh nice, I'll give this a try!

dylang on 18 Dec 2018

hello @dylang, did you try ?

christophehurpeau on 12 Feb 2019

I often have the same problem and would love this option. I tested yarn-deduplicate and it does what I want. npm also has this built in as the npm dedupe command.

felixfbecker on 23 Feb 2019

OK, I will add a new dedupe option valid for yarn or npm only that runs the dedupe command after any lockfile update, if enabled.

rarkins on 24 Feb 2019

@felixfbecker do you have an example of when yarn-deduplicate works. I was just testing out and am very confused.

Take this package.json:

{
  "name": "tmp2",
  "version": "1.0.0",
  "devDependencies": {
    "@types/react": "16.7.0",
    "@types/react-dom": "^16.0.0"
  }
}

Here's the resulting yarn.lock:

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1


"@types/prop-types@*":
  version "15.5.9"
  resolved "https://registry.yarnpkg.com/@types/prop-types/-/prop-types-15.5.9.tgz#f2d14df87b0739041bc53a7d75e3d77d726a3ec0"
  integrity sha512-Nha5b+jmBI271jdTMwrHiNXM+DvThjHOfyZtMX9kj/c/LUj2xiLHsG/1L3tJ8DjAoQN48cHwUwtqBotjyXaSdQ==

"@types/react-dom@^16.0.0":
  version "16.8.2"
  resolved "https://registry.yarnpkg.com/@types/react-dom/-/react-dom-16.8.2.tgz#9bd7d33f908b243ff0692846ef36c81d4941ad12"
  integrity sha512-MX7n1wq3G/De15RGAAqnmidzhr2Y9O/ClxPxyqaNg96pGyeXUYPSvujgzEVpLo9oIP4Wn1UETl+rxTN02KEpBw==
  dependencies:
    "@types/react" "*"

"@types/react@*":
  version "16.8.4"
  resolved "https://registry.yarnpkg.com/@types/react/-/react-16.8.4.tgz#134307f5266e866d5e7c25e47f31f9abd5b2ea34"
  integrity sha512-Mpz1NNMJvrjf0GcDqiK8+YeOydXfD8Mgag3UtqQ5lXYTsMnOiHcKmO48LiSWMb1rSHB9MV/jlgyNzeAVxWMZRQ==
  dependencies:
    "@types/prop-types" "*"
    csstype "^2.2.0"

"@types/[email protected]":
  version "16.7.0"
  resolved "https://registry.yarnpkg.com/@types/react/-/react-16.7.0.tgz#d33202339d6fb672c2ad0930c835ecf8ae0ac521"
  integrity sha512-bHwfht6kILzUj1Hs5vmr9vpokDmcNXPbR55tKE/ZEylb3WtSt9hAuO68rsm73/sre2/MwLijfo8sD4ANe+HDUg==
  dependencies:
    "@types/prop-types" "*"
    csstype "^2.2.0"

csstype@^2.2.0:
  version "2.6.2"
  resolved "https://registry.yarnpkg.com/csstype/-/csstype-2.6.2.tgz#3043d5e065454579afc7478a18de41909c8a2f01"
  integrity sha512-Rl7PvTae0pflc1YtxtKbiSqq20Ts6vpIYOD5WBafl4y123DyHUeLrRdQP66sQW8/6gmX8jrYJLXwNeMqYVJcow==

You can see that there are two different versions of @types/react installed - which seems wrong to me to begin with. npm has just a single version without any de-duplication necessary. Running yarn-deduplicate produces no stdout and no difference to yarn.lock.

rarkins on 24 Feb 2019

Never mind, apparently yarn-deduplicate defaults to "highest" strategy, which still leaves in duplicates. Adding -s fewer results in the behaviour I was expecting.

rarkins on 24 Feb 2019

👍2

Sounds good to me. The problem here was that @types/react-dom depends on @types/react@*, which yarn resolved to 16.8.4 initially, which is higher than 16.7.0.highestbasically means "never downgrade".fewest` means "downgrade if (and only if) needed".

npm seems to already downgrade on install with the * range. I definitely know it's possible though to end up in a state with duplicated packages, so this feature would still be useful for npm.

felixfbecker on 24 Feb 2019

Excited to try this with the new lock file maintenance!

felixfbecker on 24 Feb 2019

I set up a CI check to fail with yarn-deduplicate --fail if packages are duplicated: https://github.com/sourcegraph/sourcegraph-typescript/pulls
Let me know when the option is out and I'll try it out!

felixfbecker on 26 Feb 2019

:tada: This issue has been resolved in version 14.41.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: