close #7444 Peer dependencies of peer dependencies are now resolved correctly. When peer dependencies have peer dependencies of their own, the peer dependencies are grouped with their own peer dependencies before being linked to their dependents. For instance, if `card` has `react` in peer dependencies and `react` has `typescript` in its peer dependencies, then the same version of `react` may be linked from different places if there are multiple versions of `typescript`. For instance: ``` project1/package.json { "dependencies": { "card": "1.0.0", "react": "16.8.0", "typescript": "7.0.0" } } project2/package.json { "dependencies": { "card": "1.0.0", "react": "16.8.0", "typescript": "8.0.0" } } node_modules .pnpm card@1.0.0(react@16.8.0(typescript@7.0.0)) node_modules card react --> ../../react@16.8.0(typescript@7.0.0)/node_modules/react react@16.8.0(typescript@7.0.0) node_modules react typescript --> ../../typescript@7.0.0/node_modules/typescript typescript@7.0.0 node_modules typescript card@1.0.0(react@16.8.0(typescript@8.0.0)) node_modules card react --> ../../react@16.8.0(typescript@8.0.0)/node_modules/react react@16.8.0(typescript@8.0.0) node_modules react typescript --> ../../typescript@8.0.0/node_modules/typescript typescript@8.0.0 node_modules typescript ``` In the above example, both projects have `card` in dependencies but the projects use different versions of `typescript`. Hence, even though the same version of `card` is used, `card` in `project1` will reference `react` from a directory where it is placed with `typescript@7.0.0` (because it resolves `typescript` from the dependencies of `project1`), while `card` in `project2` will reference `react` with `typescript@8.0.0`.
@pnpm/core
Fast, disk space efficient installation engine. Used by pnpm
Install
Install it via npm.
pnpm add @pnpm/core
It also depends on @pnpm/logger version 1, so install it as well via:
pnpm add @pnpm/logger@1
API
mutateModules(importers, options)
TODO
link(linkFromPkgs, linkToModules, [options])
Create symbolic links from the linked packages to the target package's node_modules (and its node_modules/.bin).
Arguments:
linkFromPkgs- String[] - paths to the packages that should be linked.linkToModules- String - path to the dependent package'snode_modulesdirectory.options.reporter- Function - A function that listens for logs.
linkToGlobal(linkFrom, options)
Create a symbolic link from the specified package to the global node_modules.
Arguments:
linkFrom- String - path to the package that should be linked.globalDir- String - path to the global directory.options.reporter- Function - A function that listens for logs.
linkFromGlobal(pkgNames, linkTo, options)
Create symbolic links from the global pkgNames to the linkTo/node_modules folder.
Arguments:
pkgNames- String[] - packages to link.linkTo- String - package to link to.globalDir- String - path to the global directory.options.reporter- Function - A function that listens for logs.
storeStatus([options])
Return the list of modified dependencies.
Arguments:
options.reporter- Function - A function that listens for logs.
Returns: Promise<string[]> - the paths to the modified packages of the current project. The paths contain the location of packages in the store,
not in the projects node_modules folder.
storePrune([options])
Remove unreferenced packages from the store.
Hooks
Hooks are functions that can step into the installation process.
readPackage(pkg: Manifest): Manifest | Promise<Manifest>
This hook is called with every dependency's manifest information.
The modified manifest returned by this hook is then used by @pnpm/core during installation.
An async function is supported.
Example:
const { installPkgs } = require('@pnpm/core')
installPkgs({
hooks: {readPackage}
})
function readPackage (pkg) {
if (pkg.name === 'foo') {
pkg.dependencies = {
bar: '^2.0.0',
}
}
return pkg
}
afterAllResolved(lockfile: Lockfile): Lockfile | Promise<Lockfile>
This hook is called after all dependencies are resolved. It receives and returns the resolved lockfile object. An async function is supported.