`bun install --save-text-lockfile` generates incompatible `bun.lock`

[dvopalecky]

What version of Bun is running?

1.1.40+b5b51004e

What platform is your computer?

Darwin 23.6.0 arm64 arm

What steps can reproduce the bug?

Bug Report

I am trying to to migrate from bun.lockb to bun.lock without changing the exact dependencies. bun install --save-text-lockfile produces a bun.lock file that seems incompatible with subsequent --frozen-lockfile operations, leading to errors.

Steps to Reproduce:

1. Create a repository with attached files:

• package.json
• bun.lockb.zip
  • unzip to bun.lock

2. Run bun install --frozen-lockfile.

• Expected: No changes, installation proceeds using bun.lockb.
• Actual: As expected.

3. Run bun install --save-text-lockfile.

• Expected: A bun.lock is created without issues.
• Actual: Both bun.lock and bun.lockb exist.

4. Delete bun.lockb to keep only the text lock file.
5. Run bun install --frozen-lockfile again.

• Expected: Install completes successfully using the bun.lock without any changes.
• Actual: Encounter the following error:

bun install v1.1.40 (b5b51004)
472 |     "@jest/core": ["@jest/[email protected]", "", { "dependencies": { "@jest/console": "^2
          ^
error: Unable to resolve dependencies for package
    at bun.lock:472:5
InvalidPackageInfo: failed to parse lockfile: 'bun.lock'

warn: Ignoring lockfile
error: lockfile had changes, but lockfile is frozen

What is the expected behavior?

No response

What do you see instead?

No response

Additional information

No response

[dylan-conway]

Did you have peer dependencies disabled when generating the bun.lockb? This looks like a bug where the text lockfile is not respecting peer/dev/optional = false in bunfig.toml or .npmrc

[dylan-conway]

This is a bug caused by saving a dependency tree without peer and optional packages if they're disabled. The entire dependency tree needs to be saved to disk.

[dvopalecky]

Hello @dylan-conway , thanks for looking into this. If I understand correctly, you reproduced the issue and confirmed it's a bug. I'm not too familiar with peer dependencies. I don't have any explicitly specified in my package.json. I didn't find any bunfile.toml nor .npmrc in my local folder nor in home folder, so I'm not sure where the peer dependency disabled setting could come from.

[dylan-conway]

@dvopalecky this bug was actually caused by a combination of optional peer dependencies (from "peerDependenciesMeta") and most likely handling peer dependencies incorrectly in an earlier version of bun.

#15874 will fix this bug in Bun v1.1.41, but the lockfile will need to be edited manually. This is the updated version bun.lock.zip. Example of diff, adding "optionalPeers" for a few packages:

+ "dedent": ["[email protected]", "", { "peerDependencies": { "babel-plugin-macros": "^3.1.0" }, "optionalPeers": ["babel-plugin-macros"] } ],
- "dedent": ["[email protected]", "", { "peerDependencies": { "babel-plugin-macros": "^3.1.0" } } ],

Thanks for opening this issue. It helped us fix important bugs.

[redbmk]

@dylan-conway I think this should be re-opened. I'm still able to recreate this following the same steps as OP (using their package.json and bun.lockb) using bun 1.2.

I've also created another minimal example. In my case, I can recreate this without using a bunfig.toml, and I never changed the defaults regarding peer/dev/optional dependencies. My lockfile was much larger but I was able to shrink it down with bun 1.1.39 to just langchain.

bun.lockb.zip

here's a minimal package.json that goes with it:

{
  "name": "testing",
  "dependencies": {
    "langchain": "^0.0.194"
  }
}

With bun 1.2, I can install using a frozen lockfile just fine

❯ bun i
bun install v1.2.0 (b0c5a765)

Checked 68 installs across 69 packages (no changes) [36.00ms]
❯ bun i --frozen-lockfile
bun install v1.2.0 (b0c5a765)

Checked 68 installs across 69 packages (no changes) [28.00ms]

And everything appears to work fine at first when I try to save it to a text lockfile, except a couple things happen:

1. A second attempt to install with a --frozen-lockfile fails.
2. The lockfile's workspace name doesn't match the name in package.json, but instead the original name from the binary lockfile which apparently never updated even with bun i (a separate bug?)
3. If I don't use a frozen lockfile, it will warn that it ignored the lockfile, updating dependencies, and finally update the workspace name. It still doesn't install the peer dependency that was originally causing the issue, though it does still appear in the newly created bun.lock file.

❯ bun i --frozen-lockfile --save-text-lockfile
bun install v1.2.0 (b0c5a765)

Checked 68 installs across 69 packages (no changes) [33.00ms]
❯ bun i --frozen-lockfile --save-text-lockfile
bun install v1.2.0 (b0c5a765)
82 |     "langchain": ["[email protected]", "", { "dependencies": { "@anthropic-ai/sdk":
         ^
error: Failed to resolve peer dependency '@aws-crypto/sha256-js' for package 'langchain'
    at bun.lock:82:5
InvalidPackageInfo: failed to parse lockfile: 'bun.lock'

warn: Ignoring lockfile
error: lockfile had changes, but lockfile is frozen
❯ ls node_modules/@aws-crypto
ls: node_modules/@aws-crypto: No such file or directory
❯ head -5 bun.lock
{
  "lockfileVersion": 1,
  "workspaces": {
    "": {
      "name": "eassist",
❯ bun i
bun install v1.2.0 (b0c5a765)
82 |     "langchain": ["[email protected]", "", { "dependencies": { "@anthropic-ai/sdk":
         ^
error: Failed to resolve peer dependency '@aws-crypto/sha256-js' for package 'langchain'
    at bun.lock:82:5
InvalidPackageInfo: failed to parse lockfile: 'bun.lock'

warn: Ignoring lockfile

13 packages installed [2.17s]
❯ ls node_modules/@aws-crypto
ls: node_modules/@aws-crypto: No such file or directory
❯ head -5 bun.lock
{
  "lockfileVersion": 1,
  "workspaces": {
    "": {
      "name": "testing",

[redbmk]

but the lockfile will need to be edited manually

I hadn't noticed this part before. So, we just need to add optionalPeers for any of the packages that were having issues?

EDIT: OK, that seemed to do it. It would be nice if --save-text-lockfile could resolve this automatically, but at least it's fixable and doesn't seem to happen in most cases.

[dylan-conway]

@redbmk Yes, editing optionalPeers manually is the fix at the moment. I agree, --save-text-lockfile should be able to do this automatically, will attempt implementing this.