(Regression) `bun install --frozen-lockfile` keeps reporting issues

[lordphnx]

What version of Bun is running?

1.2.10+db2e7d7f7

What platform is your computer?

Darwin 24.4.0 arm64 arm

What steps can reproduce the bug?

We are experiencing a regression of #16692 in 1.2.10:

• I have a typescript monorepo with multiple workspaces
• Installing locally (Darwin arm64) gives me a bun.lock file
• Then trying to install in CI with --frozen-lockfile yields:

bun install v1.2.10 (db2e7d7f)
error: lockfile had changes, but lockfile is frozen
note: try re-running without --frozen-lockfile and commit the updated lockfile

(Potentially due to CI being linux/x64 and locally being installed on dawin/arm64?)

What is the expected behavior?

I expect identical behaviour to npm ci:

Lockfile just installs exactely the versions in the lock file, potentially adding architecture-specific optionalDependencies

What do you see instead?

bun install v1.2.10 (db2e7d7f)
error: lockfile had changes, but lockfile is frozen
note: try re-running without --frozen-lockfile and commit the updated lockfile

Additional information

• For compatibility, some packages still have @swc/core, which has a specific package for each specific architecture.

[dylan-conway]

Would you be able to share the lockfile and each package.json from your monorepo? It would help us narrow down this bug. The only information we need from the package.jsons is dependency information and relative path to root package.json

[lordphnx]

Would you be able to share the lockfile and each package.json from your monorepo? It would help us narrow down this bug. The only information we need from the package.jsons is dependency information and relative path to root package.json

Hey Dylan, I can do a redacted lock file, but I have 200+ package.jsons, so I guess that defeats the purpose.

Could I:

• run bun install locally
• get that lock file (A)
• run bun install in CI
• get that lock file (B)

And get you redacted versions of those?

[hirbod]

We just ran into the same issue. It was broken forever, started working in 1.2.7, and broke again today after we made a huge upgrade (Expo SDK 52 to 53). Not sure what type of package.json, overrides, or peerDependencies are causing this, but we simply cannot use –frozen-lockfile.

[Jarred-Sumner]

@hirbod if you one off delete bun.lock does it continue to reproduce?

[hirbod]

Yes, it continues to reproduce. We have a monorepo and a override for @expo/metro-runtime": "5.0.2 in our root package.json, but expo-router requires @expo/metro-runtime": "5.0.3 and this seems to break --frozen-lockfile.

So this seems to be the problem @Jarred-Sumner

Also maybe "incorrect peer dependecy" warnings could be the problem?

Edit:
So far nothing we tried helped.

[benpsnyder]

Sorry I am not posting more helpful debug output but just weighing in here that in our docker container, bun install --frozen-lockfile remains broken. You can see from this screenshot it does succeed on the build host directly.

[hirbod]

Adding --verbose also shows not very helpful traces

Workspace package "apps/expo" has added 0 dependencies, removed 0 dependencies, and updated 1 dependencies
-
-
-
-
Clean lockfile: 2483 packages - 2483 packages in 4.9ms
error: lockfile had changes, but lockfile is frozen

Just always that random "updated 1 dependencies"

[hirbod]

Ok, so @jorgeavaldez changed packageManager to yarn, ran turbo clean, then yarn complained.
Turns out changing "vitest": "~3.1.1" to "vitest": "3.1.1" across all our monorepo package.json files fixed the issue.

I hope this gives you the right trace @Jarred-Sumner to look into the fix.
Thanks to yarn, Jorge was able to pinpoint the problem.

So the problem is that vitest was in both dependencies and devDependencies

[benpsnyder]

Sorry I am not posting more helpful debug output but just weighing in here that in our docker container, bun install --frozen-lockfile remains broken. You can see from this screenshot it does succeed on the build host directly.

In our repo, we have this for workspaces

I was able to get a bun install lockfile output inside docker and it looks like it excludes mods/keycloakify

I realized my stupidity, and added this missing line

--frozen-lockfile does in fact succeed for our repo. False alarm on my end; our error!