Follow-up from #1095 (review thread #1095 (comment)).
scripts/install.sh.tftpl:126 (wanted_mux_version, bun branch). #1095 made the warm-start version check work on Bun releases before 1.2.15, which have no bun pm view, by falling back to npm view and then to a plain curl against the registry. Both fallbacks only see credentials that live in .npmrc (or none at all). When a forced package_manager = "bun" on Bun <= 1.2.14 talks to a private registry whose token is configured only through Bun (bunfig.toml [install] registry = { url, token }, [install.scopes], or BUN_CONFIG_REGISTRY), bun add installs fine but neither fallback can resolve the wanted version. The comparison then fails on every start and Mux is reinstalled each time, which is the behavior #1095 set out to remove. The combination is narrow (old Bun, private registry, Bun-only credentials) and was left out of #1095 to keep it to the persistent, version-aware install.
Suggested fix: resolve through Bun itself so its own auth applies on every supported release. bun add --dry-run --ignore-scripts --registry <url> mux@<version> runs inside the npm/ work directory, writes nothing, and prints installed mux@<resolved> with binaries: on Bun 1.2.14 (verified); parse that line when bun pm view exits non-zero, before falling back to npm/curl. It does resolve the full dependency tree from registry metadata, so it costs more than bun pm view, but far less than the install it avoids. Alternatives: read the token from bunfig.toml / BUN_CONFIG_REGISTRY and pass it as an Authorization header on the curl lookup (more parsing, and it duplicates Bun's config resolution). bun info and bun pm pkg do not exist on 1.2.14 (bun info is a reserved stub even on 1.2.15), so they are not options.
A container test would run oven/bun:1.2.14-alpine against a token-protected registry stub (for example verdaccio or a tiny HTTP server that 401s without Authorization), with the token only in bunfig.toml, and assert the second start skips.
Xum acted on behalf of @ibetitsmike when filing this issue.
Follow-up from #1095 (review thread #1095 (comment)).
scripts/install.sh.tftpl:126(wanted_mux_version, bun branch). #1095 made the warm-start version check work on Bun releases before 1.2.15, which have nobun pm view, by falling back tonpm viewand then to a plaincurlagainst the registry. Both fallbacks only see credentials that live in.npmrc(or none at all). When a forcedpackage_manager = "bun"on Bun <= 1.2.14 talks to a private registry whose token is configured only through Bun (bunfig.toml[install] registry = { url, token },[install.scopes], orBUN_CONFIG_REGISTRY),bun addinstalls fine but neither fallback can resolve the wanted version. The comparison then fails on every start and Mux is reinstalled each time, which is the behavior #1095 set out to remove. The combination is narrow (old Bun, private registry, Bun-only credentials) and was left out of #1095 to keep it to the persistent, version-aware install.Suggested fix: resolve through Bun itself so its own auth applies on every supported release.
bun add --dry-run --ignore-scripts --registry <url> mux@<version>runs inside thenpm/work directory, writes nothing, and printsinstalled mux@<resolved> with binaries:on Bun 1.2.14 (verified); parse that line whenbun pm viewexits non-zero, before falling back to npm/curl. It does resolve the full dependency tree from registry metadata, so it costs more thanbun pm view, but far less than the install it avoids. Alternatives: read the token frombunfig.toml/BUN_CONFIG_REGISTRYand pass it as anAuthorizationheader on the curl lookup (more parsing, and it duplicates Bun's config resolution).bun infoandbun pm pkgdo not exist on 1.2.14 (bun infois a reserved stub even on 1.2.15), so they are not options.A container test would run
oven/bun:1.2.14-alpineagainst a token-protected registry stub (for example verdaccio or a tiny HTTP server that 401s withoutAuthorization), with the token only inbunfig.toml, and assert the second start skips.