yarn 3: invalid result when Yarn up modifies package.json files #20281
Comments
mtlewis
added
priority-5-triage
status:requirements
|
This is the yarn command run: |
|
this is an edge case. the |
|
Perhaps it makes sense to open a yarn issue to cover this? Based on my (admittedly naive!) interpretation of the situation, it seems like there's a bug (rather than a limitation) with the way yarn handles |
|
no, it also changes the lockfile, but renovate isn't expecting a package.json change, so that file is omitted from git commit. that's why you see them missing on PR. also yarn seems to use the last dep from cli args if the same package is passed multiple times. @rarkins maybe we need to check for changed package.json files and commit them in case yarn changed them? |
Surely if
Want to highlight that even if changes to package.json were included, mtlewis/renovate-yarn-repro#1 would still be incorrect. The version of |
|
Reproduction forked to https://github.com/renovate-reproductions/20281 |
|
I updated the commands we run to target workspaces, e.g.
diff --git a/packages/package-1/package.json b/packages/package-1/package.json
index 9057fe3..9759a33 100644
--- a/packages/package-1/package.json
+++ b/packages/package-1/package.json
@@ -4,6 +4,6 @@
"license": "UNLICENSED",
"private": true,
"devDependencies": {
- "@types/express": "*"
+ "@types/express": "^4.17.16"
}
}
diff --git a/yarn.lock b/yarn.lock
index 73e629a..19272df 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -9,7 +9,7 @@ __metadata:
version: 0.0.0-use.local
resolution: "@renovate-yarn-repro/package-1@workspace:packages/package-1"
dependencies:
- "@types/express": "*"
+ "@types/express": ^4.17.16
languageName: unknown
linkType: soft
@@ -49,26 +49,26 @@ __metadata:
languageName: node
linkType: hard
-"@types/express-serve-static-core@npm:^4.17.31":
- version: 4.17.31
- resolution: "@types/express-serve-static-core@npm:4.17.31"
+"@types/express-serve-static-core@npm:^4.17.33":
+ version: 4.17.33
+ resolution: "@types/express-serve-static-core@npm:4.17.33"
dependencies:
"@types/node": "*"
"@types/qs": "*"
"@types/range-parser": "*"
- checksum: 009bfbe1070837454a1056aa710d0390ee5fb8c05dfe5a1691cc3e2ca88dc256f80e1ca27cb51a978681631d2f6431bfc9ec352ea46dd0c6eb183d0170bde5df
+ checksum: dce580d16b85f207445af9d4053d66942b27d0c72e86153089fa00feee3e96ae336b7bedb31ed4eea9e553c99d6dd356ed6e0928f135375d9f862a1a8015adf2
languageName: node
linkType: hard
-"@types/express@npm:*, @types/express@npm:^4.17.16":
- version: 4.17.16
- resolution: "@types/express@npm:4.17.16"
+"@types/express@npm:^4.17.16":
+ version: 4.17.17
+ resolution: "@types/express@npm:4.17.17"
dependencies:
"@types/body-parser": "*"
- "@types/express-serve-static-core": ^4.17.31
+ "@types/express-serve-static-core": ^4.17.33
"@types/qs": "*"
"@types/serve-static": "*"
- checksum: 43f3ed2cea6e5e83c7c1098c5152f644e975fd764443717ff9c812a1518416a9e7e9f824ffe852c118888cbfb994ed023cad08331f49b19ced469bb185cdd5cd
+ checksum: 0196dacc275ac3ce89d7364885cb08e7fb61f53ca101f65886dbf1daf9b7eb05c0943e2e4bbd01b0cc5e50f37e0eea7e4cbe97d0304094411ac73e1b7998f4da
languageName: node
linkType: hardi.e. it's change the So assuming you still think that's wrong, unfortunately it's |
|
Created an issue in the Yarn repo: yarnpkg/berry#5365 |
rarkins
changed the title
|
I've modified the title of this to try to capture the broader problem here. It's like this:
If we get an answer back from the Yarn project soon (with much appreciation to @arcanis if possible) that it's a bug which will be soon addressed, then we'll wait for that and probably close this issue once the updated Yarn is available. If it's not a bug, or it isn't likely to be fixed soon, we'll at least need to adjust Renovate's behavior to look for |
That's expected. The purpose of the |
|
@arcanis thanks. So if you run In the reproduction scenario:
Locked version (common) for them is 4.17.16 currently. We can't figure out a way to upgrade the locked version to 4.17.7 without one of the workspaces having their package.json constraint changed. |
Yep - That said, what you describe (upgrading without bumping the version in the package.json files) can be achieved by adding the
Keep in mind that:
|
|
Thanks @arcanis, I have raised #21309 in order to fix the problem. I think that our users would prefer that Renovate could specify the exact version to update a locked dependency to, but that doesn't appear possible right now. We might for example tell them we're updating a range to 1.0.8 but actually update to 1.0.9, but that's hopefully a rare edge case. |
|
🎉 This issue has been resolved in version 35.32.1 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
|
Hey folks, really appreciate the fix! Just re-ran renovate in the original repro PR above, and it now seems to me to be doing the correct thing. Thanks a lot! |
How are you running Renovate?
Mend Renovate hosted app on github.com
If you're self-hosting Renovate, tell us what version of Renovate you run.
No response
If you're self-hosting Renovate, select which platform you are using.
None
If you're self-hosting Renovate, tell us what version of the platform you run.
No response
Was this something which used to work for you, and then stopped?
I never saw this working
Describe the bug
It seems like Renovate is failing to correctly apply
update-lockfileupdates when a single package is depended on via different version ranges across packages in a monorepo.Here's a minimal repro: https://github.com/mtlewis/renovate-yarn-repro
You'll notice that package-1 depends on
@types/express@*, while package-2 depends on@types/express@^4.17.16. Inmain, the package version is locked to v4.17.16.While renovate correctly opened mtlewis/renovate-yarn-repro#1 to update the package to v4.17.17, the yarn.lock file:
@types/expressto*.@types/expressat all - the diff does not reflect the PR description, in that even after re-running yarn locally, the version of@types/expressin use in the repo stays at 4.17.16.Relevant debug logs
Logs
Have you created a minimal reproduction repository?
I have linked to a minimal reproduction repository in the bug description
The text was updated successfully, but these errors were encountered: