-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Fix: Resolve peerDependencies from all higher levels, not just root #4478
Conversation
**Summary** Fixes #4446, fixes #4433. Follow up to #3893. The fix in #3893 was too aggressive, allowing only top-level dependencies to be used in peer dependency resolution which was incorrect. This patch allows resolving peer dependencies from the same or higher levels in the dependency tree. **Test plan** Additional unit and integration tests.
I've tested this with the mentioned issues and it seems to fix them both. I'll also test tihs with other similar issues and |
package.json
Outdated
@@ -40,7 +40,7 @@ | |||
"request": "^2.81.0", | |||
"request-capture-har": "^1.2.2", | |||
"rimraf": "^2.5.0", | |||
"semver": "^5.1.0", | |||
"semver": "^5.4.1", |
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.
This update is not required so I can revert if you want.
This change will increase the build size from 9.69 MB to 9.69 MB, an increase of 1.55 KB (0%)
|
src/package-linker.js
Outdated
const {root, version} = pkg._reference || {}; | ||
return root && this._satisfiesPeerDependency(range, version); | ||
const {level, version} = pkg._reference || {}; | ||
return level <= ref.level && this._satisfiesPeerDependency(range, version); |
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.
I think we should be prioritizing some links over others, i.e. top level dependency should satisfy its dependencies from root (same level). I'm not sure whether a nested dependency should satisfy it from root first or sibling first. But maybe instead of find, we need to add it to a collection and then pick out either the lowest level or closest level match. WDYT?
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.
Good thinking! I think it should resolve to the closest. I'll update the code.
@kaylieEB updated per your suggestion. Also tested with |
src/package-linker.js
Outdated
if (resolvedPeerPkgPattern) { | ||
ref.addDependencies(resolvedPeerPkgPattern); | ||
} else { | ||
const depError = incorrectPeer ? 'incorrectPeer' : 'unmetPeer'; |
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.
you can define let depError = 'unmetPeer'
instead of let incorrectPeer = false
and set it to 'incorrectPeer'
above right?
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.
Hahaha, right! Stupid me. Will do that too. Rest looks fine? I'll add tests soon.
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.
yup the rest looks good!
@kaylieEB one more review, for tests please! :) |
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.
minor comment, looks good!
@@ -223,6 +223,7 @@ const messages = { | |||
|
|||
unmetPeer: '$0 has unmet peer dependency $1.', | |||
incorrectPeer: '$0 has incorrect peer dependency $1.', | |||
selectedPeer: 'Selecting $1 at level $2 as the peer dependency of $0.', |
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.
saw this earlier, nice touch!
__tests__/integration.js
Outdated
@@ -51,6 +59,7 @@ addTest('https://git@github.com/stevemao/left-pad.git'); // git url, with userna | |||
addTest('https://github.com/yarnpkg/yarn/releases/download/v0.18.1/yarn-v0.18.1.tar.gz'); // tarball | |||
addTest('https://github.com/bestander/chrome-app-livereload.git'); // no package.json | |||
addTest('bestander/chrome-app-livereload'); // no package.json, github, tarball | |||
addTest('react-scripts', {strict: true}); // many peer dependencies, there shouldn't be any peerDep warnings |
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.
I wonder if we should fix this version in case the react-scripts package does get updated?
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.
Ahh, another good insight. Update coming.
If this is now fixed, which version of yarn should we see it in 1.0.3? |
@Gargoyle 1.1.0, which is around the corner. It is a minor version upgrade instead of a patch release since it will have some features like performance improvements. |
To be specific, not because of this PR but others :) |
With yarn@1.1.0 `aio/` and some guide examples fail to build. The failures seem to be caused by something (possibly `@ngtools/webpack`, which is a dependency of `@angular/cli`) which peer-depends on TypeScript (TS@^2.0.2), getting linked to a higher version (TS@2.4.1) with yarn@1.1.0, which is stricter than the 2.3.2 version we use on `aio/` (and which that something gets linked to with yarn@1.0.2). [This change][1] is what is causing this difference in behavior. Downgrading yarn to v1.0.2 (same we use on master) for now. [1]: yarnpkg/yarn#4478
With yarn@1.1.0 `aio/` and some guide examples fail to build. The failures seem to be caused by something (possibly `@ngtools/webpack`, which is a dependency of `@angular/cli`) which peer-depends on TypeScript (TS@^2.0.2), getting linked to a higher version (TS@2.4.1) with yarn@1.1.0, which is stricter than the 2.3.2 version we use on `aio/` (and which that something gets linked to with yarn@1.0.2). [This change][1] is what is causing this difference in behavior. Downgrading yarn to v1.0.2 (same we use on master) for now. [1]: yarnpkg/yarn#4478
…arnpkg#4478) **Summary** Fixes yarnpkg#4446, fixes yarnpkg#4433, fixes yarnpkg#2688, fixes yarnpkg#2387. Follow up to yarnpkg#3803. The fix in yarnpkg#3893 was too aggressive, allowing only top-level dependencies to be used in peer dependency resolution which was incorrect. This patch allows resolving peer dependencies from the same or higher levels in the dependency tree. **Test plan** Additional unit and integration tests.
…kg#4644) * chore(resolver): Minor improvements in resolver code and tests **Summary** This is a follow up to yarnpkg#4484 and yarnpkg#4478 which improves the code around those areas a bit and removes a now-unnecessary `while` loop. **Test plan** Existing tests should pass. * Fix logic
Summary
Fixes #4446, fixes #4433, fixes #2688, fixes #2387. Follow up to #3803. The fix in #3893 was
too aggressive, allowing only top-level dependencies to be used in
peer dependency resolution which was incorrect. This patch allows
resolving peer dependencies from the same or higher levels in the
dependency tree.
Test plan
Additional unit and integration tests.