-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump yarn to 4.5.3 #11123
Bump yarn to 4.5.3 #11123
Conversation
Closes #8265 |
This is the failing test: dependabot-core/npm_and_yarn/spec/dependabot/npm_and_yarn/update_checker/version_resolver_spec.rb Lines 855 to 875 in 8f037cf
Full commit including lockfiles: 1dcda58 Interestingly, it doesn't fail in Yarn Poking through the changelog between 4.3.1 and 4.5.3, this seems to be relevant upstream PR: My understanding of peer dependency handling in Yarn is hazy at best, but after reading the PR description, it looks like the algorithm changed and now the peer dependency can be updated and not necessarily held back. That would explain this test failure:
|
@yeikel does ☝️ sound reasonable to you? I am not very familiar with Yarn Berry or peer dependencies in the yarn ecosystem... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yeikel does ☝️ sound reasonable to you? I am not very familiar with Yarn Berry or peer dependencies in the yarn ecosystem...
Yes it does. Your analysis seems correct to me.
48e21e1
to
bec32f4
Compare
This is the failing test: https://github.com/dependabot/dependabot-core/blob/8f037cf1be97f2a0c1f383d74479ebe2a48e0c17/npm_and_yarn/spec/dependabot/npm_and_yarn/update_checker/version_resolver_spec.rb#L855-L875 Full commit including lockfiles: 1dcda58 Interestingly, it doesn't fail in Yarn `4.3.1` as seen in: * #8265 Poking through the changelog between 4.3.1 and 4.5.3, this seems to be relevant upstream PR: * yarnpkg/berry#6517 My understanding of peer dependency handling in Yarn is hazy at best, but after reading the PR description, it _looks_ like the algorithm changed and now the peer dependency can be updated and not necessarily held back. That would explain [this test failure](https://github.com/dependabot/dependabot-core/actions/runs/12307737164/job/34351931150?pr=11123#step:5:56): ``` 1) Dependabot::NpmAndYarn::UpdateChecker::VersionResolver#latest_resolvable_version with a yarn berry lockfile when updating a dependency with a peer requirement is expected to eq #<Gem::Version "15.2.0"> Failure/Error: it { is_expected.to eq(Gem::Version.new("15.2.0")) } expected: #<Gem::Version "15.2.0"> got: #<Gem::Version "16.3.1"> (compared using ==) Diff: @@ -1 +1 @@ -Gem::Version.new("15.2.0") +Gem::Version.new("16.3.1") # ./spec/dependabot/npm_and_yarn/update_checker/version_resolver_spec.rb:873:in `block (5 levels) in <top (required)>' # /home/dependabot/common/spec/spec_helper.rb:66:in `block (2 levels) in <top (required)>' # /home/dependabot/dependabot-updater/vendor/ruby/3.3.0/gems/webmock-3.24.0/lib/webmock/rspec.rb:39:in `block (2 levels) in <top (required)>' ```
bec32f4
to
10155e8
Compare
What are you trying to accomplish?
I'm debugging in this area, and want to make sure I'm working off the latest upstream changes.