Issues in monorepo with 2 different major versions of same package #33885
Unanswered
Whelch
asked this question in
Request Help
Replies: 1 comment
-
Hi there, Get your discussion fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible. Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues. Please follow these steps:
If you need help with running renovate on your minimal reproduction repository, please refer to our Running Renovate guide. The Renovate team |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
How are you running Renovate?
Self-hosted Renovate
If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.
Github, renovate version 39.136.0
Please tell us more about your question or problem
I have a monorepo library repository in which 2 distinct packages list the same dependency (eslint), but at different major versions - one is on version 8 while the other is on version 9. We have renovate configured to make distinct PRs for non-major version changes (
patch
&minor
), and a separate PR for major version changes.In our case, it seems like renovate is detecting a
minor
version bump for one of our package.json files (the one already on version 9), and incorrectly declaring the other update as aminor
version bump as wellThe renovate PR has the changes listed like this:
^8.57.1
->^9.19.0
^9.18.0
->^9.19.0
This is also happening for dependencies that aren't even being updated in both packages. For instance,
eslint-plugin-react-hooks
is only being updated in the lower-version package.json, and despite being hoisted up a whole major version, it's being declared as apatch
in the renovate table^4.6.2
->^5.1.0
Is there some way this sort of miss-attribution of what's a major vs minor version update can be configured, in our case, in a general sense? I'm aware I could target
eslint
directly, by adding a couple of packageRules like this:However, I would like to be able to ensure this doesn't happen for any packages in the future.
Logs (if relevant)
Logs
Beta Was this translation helpful? Give feedback.
All reactions