This repository has been archived by the owner on Jan 20, 2022. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Respect link deps when calculating peerDep sets
Previously, we were not including link targets in the virtual trees where peer dependency sets are calculated. Additionally, we were still using the path `/virtual-root` for the virtual node, even though this is no longer load-bearing. (And, as of the recent change to the Node printable output, no longer necessary or particularly helpful for debugging.) As a result, a link dependency from the root node like `file:../../foo` would get resolved against `/virtual-root`, resulting in `/foo`, which of course does not match any Node in the virtual tree. The outcome was an ERESOVLVE error where the `current` Node is shown as having no name or version (because it is an unsatisfied Link). The solution is two-part. First, the path of the virtual tree root now matches the path of the Node that it is sourced from. Second, any Link children of the source node have their targets mirrored in the virtual tree, resulting in them being matched appropriately. The result is that a Link dependency can now properly satisfy a peerDependency. Test shows an example of using a Link to a local Node as a workaround for a peerSet that otherwise would not be resolveable. This can of course be abused to get around valid peerDep contracts, but if they user takes it on themselves to use a local fork of a dependency, we should respect that in buildIdealTree as we do elsewhere. Fix: npm/cli#2199
- Loading branch information