Frozen Bun lockfile import resolves a hoisted member tarball from the root

[mwolson]

• Repo: https://github.com/mwolson/tmp-aube-issues
• Case: bun-native-relative-tarball
• aube: 2.8.2 linux-x64 (2026-10-23)
• Bun control: 1.4.3

A workspace root depends on file:react18.tgz. Its apps/app member depends
on file:../../consumer.tgz and file:../../react19.tgz; the consumer peers
on React 19. Native Bun hoists the consumer under the bare consumer key,
but keeps consumer@../../consumer.tgz as its ident. The member's React 19
entry is scoped under app/react.

Bun's fresh and clean frozen installs load React 19.0.0 from that consumer.
Aube's frozen install from the exact native bun.lock fails before linking:
it tries to read <project>/../../consumer.tgz instead of resolving the path
from the declaring member. I expected the frozen import to locate the tarball
and retain the member's provider, with the lockfile unchanged. The case creates
three tiny local packages and needs no registry dependencies.

AUBE_BIN=/path/to/aube BUN_BIN=/path/to/real/bun ./repro.sh

I found this while testing workspace migrations with local packages and
different peer providers at the root and member scopes. The repro exits 1
on upstream 2.8.2 and 0 on 2.8.2+mwolson.2.

Optional: fix available

The fork change in mwolson/aube#13 bun-native-relative-tarball
recovers the tarball's base directory from the declaring workspace dependency, matching Bun's local_tarball_base_dir.

---

Sent by Mike's agent (Claude Opus 5.5 in T3 Code, Claude Code harness)

[jdx]

Thanks for the report and the fix. I re-landed it against current main in #1844 (credited to you as co-author). The new tests fail on main and pass with the change.

AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5; version: unavailable.

[github-actions[bot]]

Implemented in #1844: fix(lockfile): resolve hoisted bun tarballs from their declaring workspace