This is roughly how npm@5 does it. However, pnpm does not try
to install dependencies of the file dependency, just a symlink
is created and the binstubs are linked into `node_modules/.bin`
if there are any.
BREAKING CHANGE:
file dependencies are symlinked instead of copied (packed/unpacked)
Ref #772
For correct prunning of the lockfile, it has to be known
which deps are optional. Also it has to be known which
deps are dev deps in the root.
BREAKING CHANGE:
lockfile format changed
* test(install): peer dependencies should be resolved correctly
* fix(linking): packages should not loose their peer deps
When a peer dependency is resolved not from the direct parent,
dependent packages should be duplicated with hard links in order
to preserve the correct set of resolved peer dependencies.
Semi-breaking change. The node_modules structure is changed but
doesn't need a complete removal of a node_modules created with
previous version of pnpm.
* docs: document how peer dependencies are resolved
Ref #694, Ref #726
* docs: nicer comments in code blocks
* docs: more explanation about peer deps
* perf: validating the node_modules structure to a specified depth
Ref #722
* feat: adding an update boolean property to the install API
BREAKING CHANGE:
Dependencies won't be updated when `update` is `false`.
It doesn't matter what the value of `depth` is.
`depth` is used for specifying how deep should the install
algorithm analize the dependency tree.
Ref #722
* refactor: merge new resolved deps with the previous
* fix: peers are resolved similarly during named and general install
There is no need to always run a general installation for
creating a predictable `node_modules` structure. If peers are
resolved from top dependencies, the peers are not linked to
the dependent package. The dependent package can see such peers
w/o additional manipulations
Ref #724
* fix: don't print warning when peer is resolved from top dep
* test: verify the peer warning are reported correctly
zkochan