Backport of npm#9206 to `release/v11`

…encies (npm#9238)

Backport of npm#9221 to `release/v11`.

Co-authored-by: Lovell Fuller <lovell@users.noreply.github.com>

(cherry picked from commit ccce5f6)

(cherry picked from commit 2501dd8)

(cherry picked from commit 87bb9d0)

(cherry picked from commit 6faa25e)

(cherry picked from commit 413e0a0)

(cherry picked from commit 150231d)

(cherry picked from commit b09a5ac)

(cherry picked from commit 9669d31)

Backport of npm#9163 to `release/v11`.

Co-authored-by: Josua Michalak <michalak.josua@googlemail.com>

(cherry picked from commit 0dc5585)

…#9256)

Backport of npm#9255 to `release/v11`.

Co-authored-by: Manzoor Wani <manzoorwani.jk@gmail.com>

(cherry picked from commit 27567ab)

(cherry picked from commit 79d394e)

(cherry picked from commit 799866f)

(cherry picked from commit 5af02ec)

(cherry picked from commit b9332e6)

…#9198)

In continuation of our exploration of using `install-strategy=linked` in
the [Gutenberg
monorepo](WordPress/gutenberg#75814), which
powers the WordPress Block Editor.

When using `install-strategy=linked`, npm overrides for transitive
dependencies were ignored.
The overridden version was installed but reported as `invalid` instead
of `overridden`, and with `strict-peer-deps` the install failed entirely
with `ERESOLVE`.

The root cause is that override propagation stops at Link nodes and
never reaches their targets.
Overrides propagate through the tree via `addEdgeIn` ->
`updateOverridesEdgeInAdded` -> `recalculateOutEdgesOverrides`.
When a Link node receives overrides, `recalculateOutEdgesOverrides`
iterates over `this.edgesOut` — but Links have no `edgesOut` (their
targets do).
So overrides never reach the target node's dependency edges, and those
edges use `rawSpec` instead of the overridden spec.

In the linked strategy, all packages in `node_modules/` are Links
pointing to targets in `.store/`.
This meant no overrides propagated past the first level of the
dependency tree.

The fix overrides `recalculateOutEdgesOverrides` in the `Link` class to
forward overrides to the target node.
When `buildIdealTree` creates a root Link (e.g. on macOS where `/tmp` ->
`/private/tmp`), the target Node is now created with `loadOverrides:
true` so it loads override rules from `package.json`.

The `#applyRootOverridesToWorkspaces` workaround method is removed — it
was compensating for this exact bug by detaching workspace edges whose
specs didn't match. With proper propagation, workspace edges already
have the correct overridden spec, making the workaround dead code.

## References

Fixes npm#9197

(cherry picked from commit bc32d94)

Backport of npm#9287 to `release/v11`.

Co-authored-by: Gar <gar+gh@danger.computer>

(cherry picked from commit 6628d05)

…#9283)

When a peerOptional edge conflicts, search descendants for a satisfying
node before fetching from the registry. This prevents extraneous
packages from blocking hoisting of required deps.

This fixes 1/2 or 1/3 of npm#9249. Before this change a clean install would
resolve `nm/jest-util@30` when resolving the conflict at nm/jest-util
between ts-jest's jest-util@^29||^30, and expect's ^28, which had been
placed at root. `#nodeFromEdge` would create a brand new node, matching
greatest ^30. A subequent install would mark nm/jest-util@30 as
extraneous and prune it.
This tree is valid, but ts-jest's peerOptional jest-util is unsatisfied,
while compatible jest-util are installed and duplicated.

This change reduces duplication and can prevent peerOptionals from
actively installing.

1. Now during initial installs npm will prefer hoisting a dependency to
de-dupe a peerOptional conflict over creating a new extraneous edge.
2. It doesn't solve the problem if there's no compatible version in the
sub-tree. npm will still use `#nodeFromEdge` and install an extraneous
edge.
3. It doesn't fix installs from lockfiles generated before this fix. I
think this is okay, because the trees are techincally valid, just not
optimal.

 I think a better solution to all three issues would be:
* During problemEdge conflict resolution, npm would hoist
nm/jest-util@28 under expect, without replacing it with anything.
ts-jest's peerOptional jest-util would be unsatisfied. This creates the
same tree as npm's second installs that prune extraneous.
* Check for any dependencies that can be hosited. This can run during
the initial install on problemEdge conflict resoultion, and in
pruneIdealTree on any nodes that are removed.

I think this solves all three issues. I didn't implement it because I
couldn't find a way to resolve the conflict by leaving a hole in the
tree..

(cherry picked from commit 0629fbf)

## Description

Fixes npm#9298.

`buildIdealTree` handles global updates by reading the global
`node_modules` folder directly and adding each entry as a synthetic
top-level dependency. That path did not ignore hidden entries, so a
directory like `.hidden-non-package` was converted to
`.hidden-non-package@*` and rejected by `npm-package-arg`.

This applies the same hidden-entry filter already used by `loadActual`,
so hidden directories and retired scoped package folders are not treated
as installed global packages during `npm up -g`.

## Testing

```sh
node node_modules/tap/bin/run.js workspaces/arborist/test/arborist/build-ideal-tree.js -g "update global ignores hidden"
```

```sh
npm_config_prefix=/tmp/npm-hidden-global-patched.azXmRd node . up -g
```

```sh
node . run eslint -- workspaces/arborist/lib/arborist/build-ideal-tree.js workspaces/arborist/test/arborist/build-ideal-tree.js
```

(cherry picked from commit 32940e2)

Exposes a public method on the Arborist class that builds (or reuses) an ideal tree, commits the shrinkwrap metadata, and returns the lockfile contents as a string without writing to disk.

This makes a previously-undocumented sequence (`buildIdealTree()` -> `tree.meta.commit()` -> `String(tree.meta)`) a discoverable, supported API, enabling callers to inspect, diff, or store generated lockfiles without mutating the project's package-lock.json.

(cherry picked from commit b8655c7)

…pm#9315)

Backport of npm#9309 to `release/v11`.

Co-authored-by: Manzoor Wani <manzoorwani.jk@gmail.com>

Backport of npm#9311 to `release/v11`.

Co-authored-by: Mikael Kristiansson <1733784+mikaelkristiansson@users.noreply.github.com>

Backport of npm#9317 to `release/v11`.

Co-authored-by: Michael Smith <owlstronaut@github.com>

(cherry picked from commit 37bd0c6)

…llution

Sanitize __proto__, constructor, and prototype keys in the setKeys
function to prevent prototype pollution via npm pkg set. Previously,
passing __proto__.scripts.postinstall as a key would pollute
Object.prototype, causing @npmcli/package-json to write inherited
properties to disk and enabling RCE on next npm install.

Fixes GHSA-jjm5-4238-9vmw

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
(cherry picked from commit 080e3b2)

…stead of a sentinel

(cherry picked from commit a81f2f8)

…installed signatures

(cherry picked from commit b97edc0)

…and deny-scripts

(cherry picked from commit 6efac6e)

(cherry picked from commit 9f3c97f)

backport of npm#9404

Backport of npm#9442 to `release/v11`.

Co-authored-by: Minh Vu <vuhoangminh97@gmail.com>

Backport of npm#9436 to `release/v11`.

Co-authored-by: Dexter.k <164054284+rootvector2@users.noreply.github.com>

Backport of npm#9446 to `release/v11`.

Co-authored-by: Dexter.k <164054284+rootvector2@users.noreply.github.com>

with new --allow-publish/--allow-staged-publish the minimum version
of npm needed for the trust command has changed

(cherry picked from commit aac80dc)

…s warnings (npm#9481)

Backport of npm#9469 to `release/v11`.

Co-authored-by: Jamie Magee <jamie.magee@gmail.com>

…et (npm#9482)

Backport of npm#9479 to `release/v11`.

Co-authored-by: Jamie Magee <jamie.magee@gmail.com>

…and link (npm#9462)

Backport of npm#9456 to `release/v11`.

Co-authored-by: Jamie Magee <jamie.magee@gmail.com>

Backport of npm#9480 to `release/v11`.

Co-authored-by: Jamie Magee <jamie.magee@gmail.com>

(cherry picked from commit 275bc69)

(cherry picked from commit a105799)

(cherry picked from commit bf623e0)

Backport of npm#9490 to `release/v11`.

Co-authored-by: Rayan Salhab <r.salhab@aiyexpertsolutions.com>
Co-authored-by: cyphercodes <cyphercodes@users.noreply.github.com>

…d strategy (npm#9500)

Backport of npm#9495 to `release/v11`.

Co-authored-by: Manzoor Wani <manzoorwani.jk@gmail.com>

npm#9501)

Backport of npm#9401 to `release/v11`.

Co-authored-by: Liang <github@liangmi.dev>

… `wanted…"

This reverts commit ccffe4a.