bun manager: use --lockfile-only instead of a full install

[rg-lesmills]

Tell us more.

Happy to open a PR for this if my approach seems good.

Disclaimer: this discussion was drafted with AI assistance (Claude Sonnet 5), but reviewed and edited by me before posting.

Every other npm-ecosystem manager Renovate supports has a lockfile-only mode wired
up for artifact updates:

Manager	Command
npm	npm install --package-lock-only --no-audit
yarn classic	yarn-slim install (lockfile-only by construction)
yarn berry	yarn install --mode=update-lockfile
pnpm	pnpm install --lockfile-only
bun	bun install [--ignore-scripts] : full install

bun install has supported --lockfile-only since v1.1.43 (https://bun.com/docs/pm/cli/install#param-lockfile-only). The bun manager (https://github.com/renovatebot/renovate/blob/main/lib/modules/manager/bun/artifacts.ts#L62) never passes it, so every dependency bump on a bun-managed repo downloads and extracts the full node_modules tree, even though only the lockfile is committed.

I couldn't find any prior issue/PR/discussion about this, and the deno manager has
the identical gap called out as a TODO (https://github.com/renovatebot/renovate/blob/main/lib/modules/manager/deno/artifacts.ts#L134:
// TODO: appending --lockfile-only is better to reduce disk usage), so this
looks like an oversight rather than something already considered and rejected.

Proposed change

Minimal, mirrors the existing pnpm implementation:

- let cmd = 'bun install';
+ let cmd = 'bun install --lockfile-only';

Testing done

Before proposing this I checked whether --lockfile-only actually produces
equivalent output to a full install, since that's the load-bearing assumption.
Built local fixtures and ran real bun (1.3.14, plus 1.1.42 for the legacy binary
lockfile case) across the scenarios this manager needs to handle:

• Plain dependency bump, text bun.lock — byte-identical lockfile, no
  node_modules written.
• Workspace repo, dependency bump in a non-root package.json — identical
  lockfile, passes --frozen-lockfile.
• Lock file maintenance (delete lockfile, reinstall — matching what
  artifacts.ts does before invoking the command) — identical lockfile, passes
  --frozen-lockfile.
• Legacy binary bun.lockb format (this manager still supports it) — byte-identical
  output, stays binary (no silent migration to bun.lock), passes
  --frozen-lockfile.

The one caveat I found (oven-sh/bun#18906 : a workspace package's own version
field isn't reflected in the lockfile unless a dependency also changed) reproduces
identically with a full install, so --lockfile-only doesn't introduce any new
divergence there.

Open question for maintainers

--lockfile-only requires bun ≥1.1.43 (Dec 2024). execOptions.toolConstraints
already threads a bun version constraint through for containerbase-managed
installs, so most users will have a recent bun. But binarySource=global
self-hosted users could still have an older system bun, where this flag would
error. Worth version-gating (similar to how npm's dedupe path checks for
--prefer-dedupe support before using it,
lib/modules/manager/npm/post-update/npm.ts), or is 1.1.43 old enough to assume
unconditionally? Happy to add gating if that's the preferred approach.

[RahulGautamSingh]

Nice write-up, and thanks for doing the verification up front, it saved both ours time.

On your open question: I'd version-gate it rather than assume 1.1.43 unconditionally. The concern is binarySource=global, where a self-hosted user's system bun is whatever they installed and could predate 1.1.43. Silently appending an unsupported flag would turn a working setup into a hard error on every update .. a regression that's hard to attribute. For containerbase-managed installs toolConstraints handles the version, so those users are never the problem; it's purely the global-binary case you're protecting.

A couple of implementation notes for the PR:

• Gate on the actual resolved bun version, not the constraint. config.constraints.bun is often unset, and when set it's a range, not the binary that will run. Better to resolve the version at exec time (see how other managers detect tool versions) and only append the flag when it satisfies >=1.1.43.
• Keep the flag ordering next to the existing --ignore-scripts append so it reads as one place that assembles the command.

Happy to review the PR.