Conversation
| Package name | Version | | --- | --- | | `@yarnpkg/plugin-essentials` | `2.0.0-rc.9` | | `@yarnpkg/plugin-exec` | `2.0.0-rc.6` | | `@yarnpkg/plugin-git` | `2.0.0-rc.6` | | `@yarnpkg/plugin-init` | `2.0.0-rc.2` | | `@yarnpkg/plugin-stage` | `2.0.0-rc.5` | | `@yarnpkg/builder` | `2.0.0-rc.9` | | `@yarnpkg/cli` | `2.0.0-rc.11` | | `@yarnpkg/core` | `2.0.0-rc.11` | | `@yarnpkg/fslib` | `2.0.0-rc.7` | | `@yarnpkg/pnp` | `2.0.0-rc.7` | | `@yarnpkg/pnpify` | `2.0.0-rc.8` |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What's the problem this PR addresses?
In the context of the compatibility work ongoing at #500 and #470, we need to figure out how to detect which dependencies have a stricter contract than others regarding multiple instantiations. This isn't a problem for PnP because package instantiations follow predictable rules, but with the classic Node resolution it's a different story and we need to know it explicitly.
The initial approach used an heuristic which tried to figure out whether a package had a peer dependency by checking the version used by its parent (and assume it's a peer dep if they matched), but in practice it caused too many false positives to be viable.
How did you fix it?
This diff exposes the peer dependencies through a new
packagePeersfield returned bygetPackageInformation. The field will only be stored in the PnP map if the package actually has peer dependencies, but will always be returned bygetPackageInformation.Incidently it might also prove useful for tree traversals as you will be able to shortcut many paths that you would have crossed otherwise.