What determines hoisting order for shared transitive dependencies in npm workspaces?

Npm workspaces provide a convenient way to manage monorepos, automatically hoisting dependencies to the root node_modules where possible. However, when two workspace packages depend on different versions of the same transitive dependency, the client must decide where to place that dependency. The algorithm that drives this decision is documented in the npm workspaces release notes, but the exact tie‑breaking rules are not fully specified across major versions.

In addition, the auto‑installation of peer dependencies in workspaces has fluctuated between npm 7, 8, 9 and 10. The peerDependenciesMeta.optional flag is toggled in different releases, leaving uncertainty about when npm will install a peer automatically versus simply reporting it as unmet.

Given these ambiguities, we ask:

1. Which rule does npm use to resolve conflicting hoisting preferences when a workspace package depends on another workspace member?
2. Does npm guarantee deterministic placement of shared transitive dependencies across major versions?
3. Under what circumstances does npm automatically install peer dependencies in workspaces?