research: can bun zero-install get lockfile-like reproducible versions?

[vivek7405]

Question

Can bun zero-install (no node_modules, no bun install) get lockfile-like reproducible versions? Specifically: if we generate a bun.lock fast via bun install --lockfile-only and commit it, does bun's RUNTIME auto-install honor that lock and resolve BARE imports to the locked versions? If yes, the entire webjs pin shim (#685/#698/#699/#700/#703/#704/#709) could be deleted and the scaffold would just commit a bun.lock.

Verdict (bun 1.3.14): NO

A committed bun.lock does NOT make bun's runtime auto-install resolve bare imports. The pin shim stays. bun.lock is not a viable replacement for the zero-install default.

Empirically:

• bun install --lockfile-only works as advertised: generates bun.lock in ~220ms, writes NO node_modules. So the FAST lock generation half of the other-agent claim is TRUE.
• But the RUNTIME half is FALSE. With bun.lock pinning lodash@4.17.20, that version cached, and NO node_modules, a bare import('lodash') ENOENTs (error: ENOENT while resolving package 'lodash'), identically with or without the lock, via both bun run x.mjs and bun x.mjs. The lock is simply not consulted for bare-import resolution.
• Positive control: in the SAME dir, an INLINE import('lodash@4.17.20') resolves to 4.17.20 from cache. So the cache is fine and inline specifiers resolve reliably. Inline is exactly what the pin shim produces.
• Bare imports are also inconsistent (a cached cowsay@1.6.0, which is also latest, loaded bare; lodash@4.17.20 with latest 4.17.21 did not), matching bun's own source comment that auto-install "always installs the latest version regardless of package.json". When a bare import resolves at all it targets latest, never the locked/declared version when they differ.

Implication

1. The bun.lock path cannot delete the pin shim. The shim (rewrite bare specifier to inline-versioned) is the ONLY reliable mechanism, because inline specifiers resolve where bare ones ENOENT. This REINFORCES docs: make the bun auto-install pin shim self-documenting + deletable #714 (document the shim) and harden the bun auto-install pin shim (fail-open, capability probe, escape hatch, CI canary) #715 (harden it).
2. bun.lock as an opt-in reproducibility tier is ALSO not useful today: bun's runtime ignores it for bare resolution, so committing it buys nothing at runtime on 1.3.14. (It may help editor tooling or a future bun.)
3. The capability probe in harden the bun auto-install pin shim (fail-open, capability probe, escape hatch, CI canary) #715 is the right ongoing mechanism: if a future bun honors the lock or package.json for bare imports, the probe detects it and the shim self-disables. CI-against-canary (harden the bun auto-install pin shim (fail-open, capability probe, escape hatch, CI canary) #715) is how we learn when that day arrives. This research should be re-run on each major bun release.

Verified on bun 1.3.14. Re-test on canary / future releases via the #715 CI-canary job.

[vivek7405]

Deep-dive: the experiments (bun 1.3.14)

All runs in a throwaway dir, no node_modules, /home/vivek/.bun/bin/bun (1.3.14).

1. Lockfile-only generation (the TRUE half of the claim)

package.json: {"dependencies":{"lodash":"4.17.20"}}
$ bun install --lockfile-only
Saved bun.lock (2 packages) [220.00ms]
-> bun.lock EXISTS, pins lodash@4.17.20, NO node_modules created

So bun install --lockfile-only is fast and node_modules-free. Confirmed.

2. Does the runtime honor the lock for a bare import? (the FALSE half)

Pre-warmed the global cache with BOTH lodash@4.17.20 and lodash@4.17.21 (via bun add in throwaway dirs), so fetch is not a variable. Then in a dir with bun.lock pinning 4.17.20, no node_modules:

import('lodash')        (bun run)  -> error: ENOENT while resolving package 'lodash'
import('lodash')        (bun x.mjs)-> error: ENOENT while resolving package 'lodash'
import('lodash')        (no lock)  -> error: ENOENT  (same)
import('lodash@4.17.20')           -> 4.17.20   (POSITIVE CONTROL: cache + inline both work)

Lock present, locked version cached, bare import still ENOENTs, while the inline form of the SAME cached version resolves. The lock is not consulted.

3. Bare-import inconsistency

cowsay DECLARED 1.6.0 (=latest), cached, bare import   -> loaded
cowsay UNDECLARED,            cached, bare import       -> loaded
cowsay no package.json,       cached, bare import       -> loaded
lodash DECLARED 4.17.20 (latest 4.17.21), both cached  -> ENOENT

Bare imports resolve to LATEST when they resolve at all (cowsay 1.6.0 happens to be latest, so it "worked"); when the declared version is below latest the bare import does not honor it and here ENOENTed. This is bun's "buggy and untested" auto-install path, and it is exactly why webjs rewrites bare specifiers to inline ones (the inline control never failed).

Conclusion

The reliable primitive is the INLINE-versioned specifier, which is what the pin shim emits. bun.lock changes nothing about bare-import resolution at runtime on 1.3.14, so it cannot replace the shim. Re-test on future bun releases (the #715 capability probe + CI-canary is the standing mechanism).