What

Fixes #33192. A dependency or overrides/resolutions entry that points a name at an HTTP(S) or local tarball is now installed under the dependency key even when the tarball's own package.json name field differs, matching npm and pnpm.

Repro

// package.json
{
  "name": "app",
  "devDependencies": { "vite": "^5.0.0" },
  "overrides": { "vite": "https://example.com/vite-core.tgz" } // tarball's internal name is "@scope/vite-core"
}

$ bun install
error: vite@^5.0.0 failed to resolve
node_modules/vite: NOT INSTALLED

In graphs where the only vite edge is a transitive peer (vitest -> @vitest/mocker), bun install instead exits 0 and silently drops vite rather than erroring.

Cause

When a tarball is extracted, the resulting package is indexed in the lockfile's package index under the tarball's own package.json name (@scope/vite-core). Resolution then looks the package up by name hash.

• The direct-dependency path works because after extraction it back-propagates the extracted name onto the dependency's stored tarball version, so the re-enqueue computes hash("@scope/vite-core") and finds the package.
• The override path skipped that step: the dependency's stored version keeps its original tag (e.g. an npm range), so the back-propagation branch fell through (_ => {}), and update_name_and_name_hash_from_version_replacement returned the original name hash (hash("vite")). get_package_id(hash("vite"), ...) could not find the package indexed under hash("@scope/vite-core"), so the edge never resolved.

Fix

Two changes, both in the hoisted installer's tarball-extract path:

1. runTasks.rs: when the completed tarball's waiting dependency edge keeps its original (non-tarball) tag, it was redirected by overrides/resolutions, so record the extracted name on the override entry (keyed by the original name hash) instead of the stored version.
2. PackageManagerEnqueue.rs: once a git/github/tarball replacement's package name is known, derive the replacement's name hash from that name so resolution finds the package under the tarball's own name. While the name is still unknown (pre-extract), the original name hash is kept so the override stays keyed by its original name.

The directory name stays the overridden key (node_modules/vite), since assign_resolution only overwrites a dependency's name when it is empty or equals the version literal.

Catalog replacements are unchanged: their package name is never back-propagated, so the new helper returns the original hash (its existing behavior).

Scope

overrides that resolve to a git URL (git+..., cloned rather than tarball-extracted) are intentionally left out of this PR. They take a different completion path (Task::Tag::GitCheckout) with a pre-existing wrong-union-arm write for override edges, and git clones cannot be reproduced hermetically in the test harness, so that sibling is a follow-up. GitHub URLs are covered here because they download as tarballs through the same extract path.

Tests

test/cli/install/bun-install.test.ts, serving in-process tarballs over HTTP and from a local path:

• direct dependency resolved through a remote-tarball override with a mismatched name
• transitive peer satisfied by a remote-tarball override with a mismatched name (the issue's real-world shape)
• direct dependency resolved through a local-tarball override with a mismatched name
• override tarball whose internal name matches the key still installs (guard)

The three mismatched-name tests fail on the current binary (two with vite@^5.0.0 failed to resolve, the transitive-peer one by silently not installing vite) and pass with the fix; the matching-name guard passes both ways.