@isaacs/testing-peer-dep-conflict-chain-override-peer
v1.0.0
Published
a peer dep that is overridden by the root dependency
Downloads
10
Readme
A dependency that will first install its deps in one place, then have to have them duped to accommodate a peer dependency from another of its deps.
This models the behavior of [email protected]
gatsby -> ([email protected], @pmmmwh/[email protected])
@pmmmwh/[email protected] -> PEER [email protected]
Initially @pmmmwh/[email protected]
is installed
alongside gatsby
and [email protected]
like so:
+-- root
+-- gatsby
+-- @pmmmwh/react-refresh-webpack-plugin
+-- [email protected]
Then, the peerDep from @pmmmwh/react-refresh-webpack-plugin
on
[email protected]
is evaluated, and has nowhere to go except where the
[email protected]
is already living.
Since we can move [email protected]
underneath gatsby
, we do so.
In this case:
override -> (a@2, v@1)
v@1 -> PEER(a@1)
This fails to install by default, because the a
dep collides.
With --force
, we override the peer with the direct root dep, and get:
override
+-- v@1
+-- a@2 (valid for root, invalid for v)
+-- b@2, c@2, ...
When installing override
as a dep, we get:
push-dep
+-- v@1
+-- a@1
+-- b@1, c@1, ...
+-- override
+-- a@2
+-- b@2, c@2, ...
which is a compliant dependency resolution, where every module gets the version of their dep that they declare.