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 #9197

(cherry picked from commit bc32d94)

Backport of #9287 to `release/v11`.

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

(cherry picked from commit 6628d05)

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 #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 #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)

…9315)

Backport of #9309 to `release/v11`.

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

Backport of #9311 to `release/v11`.

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

Backport of #9317 to `release/v11`.

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

(cherry picked from commit 37bd0c6)

(cherry picked from commit af65766)

(cherry picked from commit fbe1dd0)

(cherry picked from commit 4259e57)