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.
fix: respect link deps when calc peer dep sets
* Show useful debug printing for virtual root nodes * Respect hidden lockfiles when symlink deps present. As long as the target of the link is in the shrinkwrap, and not newer. * 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 ERESOLVE 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 PR-URL: #249 Credit: @isaacs Close: #249 Reviewed-by: @ruyadorno
- Loading branch information