2624472617
* fix: respect peer dep range in hoistPeers when preferred versions exist Previously, hoistPeers used semver.maxSatisfying(versions, '*') which picked the highest preferred version from the lockfile regardless of the peer dep range. This caused overrides that narrow a peer dep range to be ignored when a stale version existed in the lockfile. Now hoistPeers first tries semver.maxSatisfying(versions, range) to find a preferred version that satisfies the actual peer dep range. If none satisfies it and autoInstallPeers is enabled, it falls back to the range itself so pnpm resolves a matching version from the registry. * fix: only fall back to exact-version range for overrides, handle workspace: protocol - When no preferred version satisfies the peer dep range, only use the range directly if it is an exact version (e.g. "4.3.0" from an override). For semver ranges (e.g. "1", "^2.0.0"), fall back to the old behavior of picking the highest preferred version for deduplication. - Guard against workspace: protocol ranges that would cause semver.maxSatisfying to throw. - Add unit tests for hoisting deduplication and workspace: ranges. * fix: only apply range-constrained peer selection for exact versions The previous approach used semver.maxSatisfying(versions, range) for all peer dep ranges, which broke aliased-dependency deduplication — e.g. when three aliases of @pnpm.e2e/peer-c existed at 1.0.0, 1.0.1, and 2.0.0, range ^1.0.0 would pick 1.0.1 instead of 2.0.0. Now the range-aware logic only activates when the range is an exact version (semver.valid), which is the override case (e.g. "4.3.0"). Regular semver ranges fall back to picking the highest preferred version.
@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.