Skip to main content
Bun’s lockfile locks package versions for reproducible installs.

Lockfile formats

Bun supports two lockfile formats:

Binary lockfile (bun.lockb)

Default format. Fast to read/write, compact size.

Text lockfile (bun.lock)

Human-readable format, better for version control diffs.

Choosing a format

Binary lockfile (default)

Best for:
  • Large projects with many dependencies
  • Faster CI/CD pipelines
  • Private projects with less merge conflicts
Advantages:
  • 3x faster to parse
  • 3x smaller file size
  • Less disk I/O
Disadvantages:
  • Not human-readable
  • Binary diffs in version control

Text lockfile

Best for:
  • Open source projects
  • Projects requiring human review of dependency changes
  • Better git diffs
Advantages:
  • Human-readable
  • Reviewable diffs
  • Easy to debug
Disadvantages:
  • Larger file size
  • Slower parsing

Configuration

Use text lockfile

Via bunfig.toml

Via CLI flag

Generate text lockfile on next install:

Convert formats

Convert binary to text:
Convert text to binary:
Or configure in bunfig.toml:

Lockfile behavior

Automatic generation

Bun automatically creates/updates the lockfile:

Lockfile updates

The lockfile updates when:
  • Installing new packages
  • Removing packages
  • Updating package versions
  • Changing version ranges in package.json

Frozen lockfile

Prevent lockfile updates (useful in CI):
Fails if lockfile is out of sync with package.json.

Via bunfig.toml

No lockfile

Install without creating/updating lockfile:

Lockfile structure

Binary lockfile

Binary format (not human-readable):

Text lockfile format

Lockfile commands

View lockfile hash

The hash represents the lockfile state.

View hash string

Migration

From other package managers

Migrate existing lockfiles:
Supported lockfiles:
  • package-lock.json (npm)
  • yarn.lock (Yarn)
  • pnpm-lock.yaml (pnpm)
Example:
Force migration (overwrite existing):

Version control

Commit lockfile

Always commit your lockfile:
If you must ignore lockfile:
Warning: This makes installs non-reproducible.

CI/CD

GitHub Actions

Cache and use lockfile:

GitLab CI

Troubleshooting

Lockfile out of sync

If lockfile doesn’t match package.json:
Fix:

Merge conflicts

For binary lockfile conflicts:
For text lockfile conflicts:

Corrupted lockfile

If lockfile is corrupted:

Different machines

If lockfile differs between machines:
  1. Ensure same Bun version:
  1. Use same registry:
  1. Regenerate lockfile:

Custom lockfile path

Set lockfile path

Or:

Save lockfile to different location

Workspaces

In workspace projects, use a single root lockfile:
All workspace dependencies are tracked in the root lockfile.

Performance

Binary lockfile

  • Read time: ~5-10ms for 1000 packages
  • Write time: ~10-20ms for 1000 packages
  • File size: ~100-200KB for 1000 packages

Text lockfile

  • Read time: ~15-30ms for 1000 packages
  • Write time: ~30-60ms for 1000 packages
  • File size: ~300-600KB for 1000 packages

Best practices

Always commit lockfile

Use frozen lockfile in CI

Review lockfile changes

For text lockfiles:
Check for:
  • Unexpected version changes
  • New dependencies
  • Removed dependencies

Regenerate periodically

Regenerate lockfile to clean up:

Use text lockfile for open source

Easier for contributors to review:

Examples

Enable text lockfile

Switch to binary lockfile

Frozen lockfile

Migrate from npm