* fix(security): harden build-approval artifact identities on v10
Port of pnpm/pnpm#12294 (commit bf1b731ee6) to release/10.
Package-name entries in onlyBuiltDependencies (and allowBuilds) no longer
approve lifecycle scripts for artifacts whose identity a name cannot pin:
git, git-hosted tarball, direct tarball, and local directory dependencies.
To approve such an artifact explicitly, use its peer-suffix-free lockfile
depPath as the key — the GIT_DEP_PREPARE_NOT_ALLOWED hint, pnpm
ignored-builds, and pnpm approve-builds print exactly that key.
- AllowBuild policy functions identify packages by DepPath instead of
caller-supplied name/version. Identity trust is derived from the depPath
shape: a registry-style depPath (name@semver) is a trusted identity.
- The trust is sound because lockfile entries are structurally checked
wherever they are materialized into fetchable resolutions
(pkgSnapshotToResolution) and before rebuild runs scripts: a
registry-style key backed by a git, directory, or git-hosted tarball
resolution is rejected with ERR_PNPM_RESOLUTION_SHAPE_MISMATCH.
- preparePackage requires a pkgResolutionId and gates on the synthesized
name@<resolution id> depPath; scp-style git URLs are normalized to
ssh:// form in resolution ids and the git fetcher reuses
createGitHostedPkgId from the resolver.
- isGitHostedTarballUrl matches case-insensitively and is shared from
@pnpm/lockfile.utils; new removePeersSuffix() in @pnpm/dependency-path
and allowBuildKeyFromIgnoredBuild() in @pnpm/builder.policy.
- pnpm rebuild and approve-builds accept depPath specs for selecting and
approving artifact builds; installs rebuild ignored builds approved by
depPath keys.
- shell-quote is overridden to 1.8.4 (GHSA-w7jw-789q-3m8p /
CVE-2026-9277).
Differences from main: v10 has no lockfile resolution verifier, so the
structural pass lives in pkgSnapshotToResolution and the rebuild loop; the
AllowBuild policy keeps v10's boolean return; the revoked-approval
detection and global-virtual-store hash changes have no v10 counterpart.
* test: serve the direct-tarball fixture from an off-registry origin
The registry mock binds only localhost, so a hard-coded 127.0.0.1 URL is
refused in CI, and a tarball URL on the registry's own origin resolves as
a registry package, which defeats the direct-tarball identity the test
needs. An in-test HTTP server redirecting to the mock provides a separate
origin whose binding the test controls.
* test: approve the git-protocol licenses fixture by its depPath
A git-hosted artifact has an untrusted package identity, so the
ajv-keywords build has to be approved by its depPath. Pin the fixture to
the commit the depPath names.
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`.
* test: use sha512 integrity in fixtures to fix ci break
* test: update snapshots for sha512 fixture change
* chore(deps): remove unneeded peer dependency exception
The `peerDependencyRules.allowedVersions` exception on
`@typescript-eslint/eslint-plugin` no longer seems to be necessary.
Removing it does not introduce any new peer dependency errors on
`pnpm install`.
I suspect this was needed for the
`eslint-config-standard-with-typescript` dependency in the past, but a
@typescript-eslint/eslint-plugin upgrade made it no longer necessary.
* chore(deps): update @typescript-eslint dependencies 5.62.0 -> 6.5.0
@typescript-eslint 6.5.0 is the first version to introduce support for
TypeScript 5.2.
https://github.com/typescript-eslint/typescript-eslint/releases/tag/v6.5.0
```
=============
WARNING: You are currently running a version of TypeScript which is not officially supported by @typescript-eslint/typescript-estree.
You may find that it works just fine, or you may not.
SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <5.2.0
YOUR TYPESCRIPT VERSION: 5.2.2
Please only submit bug reports when using the officially supported version.
```
* chore(deps): update eslint-config-standard-with-typescript 37.0.0 -> 39.0.0
Version 38.0.0 is the first version to support @typescript-eslint v6.
https://github.com/standard/eslint-config-standard-with-typescript/releases/tag/v38.0.0
Otherwise the following error appears.
```
> eslint "src/**/*.ts" "test/**/*.ts" "--fix"
Oops! Something went wrong! :(
ESLint: 8.47.0
Error: ../../.eslintrc.json » @pnpm/eslint-config » eslint-config-standard-with-typescript:
Configuration for rule "@typescript-eslint/restrict-plus-operands" is invalid:
Value {"checkCompoundAssignments":true} should NOT have additional properties.
at ConfigValidator.validateRuleOptions (/Users/gluxon/Developer/pnpm/node_modules/.pnpm/@eslint+eslintrc@2.1.2/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:2039:23)
at /Users/gluxon/Developer/pnpm/node_modules/.pnpm/@eslint+eslintrc@2.1.2/node_modules/@eslint/eslintrc/dist/eslintrc.cjs:2094:18
```
* chore: remove unnecessary disables for restrict-template-expressions
The `@typescript-eslint/restrict-template-expressions` rule relaxed
what types are allowed in template expressions.
c13ce0b4f7 (diff-b852e1e199d2976eee1183fc84ac12a5d42fc61f0ae4b1c290dd54d621546db0)
Many of these disables were for interpolated values that had an `any`
type.
* chore: remove unnecessary disables for restrict-plus-operands
The original error was:
```
Invalid operand for a '+' operation. Operands must each be a number or string. Got `any`. eslint@typescript-eslint/restrict-plus-operands
```
It look like the newer version now allows `any`.
* style: fix errors of prefer-optional-chain and prefer-nullish-coalescing
The `@typescript-eslint/prefer-optional-chain` and
`@typescript-eslint/prefer-nullish-coalescing` rules got a bit
smarter. This commit applies autofixes. I believe the changes should be
equivalent to what existed before.
Example of the new `@typescript-eslint/prefer-optional-chain` lints.
```
pnpm/pkg-manifest/exportable-manifest/src/index.ts
71:10 error Prefer using an optional chain expression instead, as it's more concise and easier to read @typescript-eslint/prefer-optional-chain
87:10 error Prefer using an optional chain expression instead, as it's more concise and easier to read @typescript-eslint/prefer-optional-chain
```
Example of the new `@typescript-eslint/prefer-nullish-coalescing` lints.
```
pnpm/fs/find-packages/src/index.ts
32:38 error Prefer using nullish coalescing operator (`??`) instead of a ternary expression, as it is simpler to read @typescript-eslint/prefer-nullish-coalescing
```
* chore(deps): update TypeScript 5.1.6 -> 5.2.2
* chore(deps): update @yarnpkg/core->@types/lodash override to 4.14.197
This fixes a compilation error that appears on TypeScript 5.2.2. This
error was fixed in a later version of `@types/lodash`.
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/66123
```
../node_modules/.pnpm/@types+lodash@4.14.181/node_modules/@types/lodash/index.d.ts:45:15 - error TS2428: All declarations of 'WeakMap' must have identical type parameters.
45 interface WeakMap<K extends object, V> { }
~~~~~~~
Found 4 errors.
```
* auto-install-peers=true
* save-workspace-protocol=rolling
* publishConfig.linkDirectory true by default
* resolve-peers-from-workspace-root is true by default
* set dedupeDirectDeps to true by default in @pnpm/core.
* fix: lockfile v6 should not be corrupted on repeat install
* fix: don't add empty specifiers to lockfile v6
* fix: lockfile v6 should be saved to node_modules/.pnpm/lock.yaml
* fix: frozen lockfile with lockfile v6
