Commit bun.lock. Since Bun v1.2 the default lockfile is the text based bun.lock, which can be read in a code review and by tools. The older binary bun.lockb can be migrated with one command and then deleted. Keeping a readable lockfile in git makes dependency changes reviewable.
What the Bun documentation says
The Bun docs state that bun install creates a lockfile called bun.lock and that it should be committed to git. They also say Bun v1.2 changed the default format to the text based bun.lock. If you still have a binary bun.lockb, the documented migration is bun install --save-text-lockfile --frozen-lockfile --lockfile-only, after which you delete bun.lockb.
Why does the format matter for security? A binary file cannot be diffed in a pull request. A text file can. When a reviewer sees a lockfile change that adds an unexpected package or moves a version, they have something to question. With a binary lockfile, that visibility is gone, and any tool that wants to read the resolved versions has to understand the binary layout.
Migration steps
- Check which file you have: bun.lock (text) or bun.lockb (binary).
- If you have only bun.lockb, run the migration command from the docs.
- Confirm bun.lock appears and the install still works.
- Delete bun.lockb and commit bun.lock.
- In CI, use
bun install --frozen-lockfileso the build fails if the lockfile and package.json disagree. The docs note that frozen mode saves nothing to disk.
Moving from another package manager
Bun can migrate other lockfiles automatically when no bun.lock exists. The docs list yarn.lock (Yarn v1 and Yarn 2 plus), npm-shrinkwrap.json and package-lock.json (lockfileVersion 2, 3 or 4), and pnpm-lock.yaml. If several exist, Bun migrates the first one it finds in this order: npm-shrinkwrap.json, package-lock.json, yarn.lock, pnpm-lock.yaml, and prints a warning for each it skips.
Two details deserve attention. An npm lockfile from npm 6 or older (lockfileVersion 1) is not migrated, and Bun resolves from package.json instead, which means versions may differ from what you had. And Bun preserves the original lockfile, so after verifying, remove the old one yourself. Leaving two lockfiles in a repository invites confusion about which one is authoritative, and some tools will read the wrong one.
| Situation | What to do |
|---|---|
| Only bun.lockb | Migrate to bun.lock, delete the binary |
| bun.lock plus an old yarn.lock | Remove the old file after verifying |
| Migrated from npm lockfileVersion 1 | Compare resolved versions, they may have changed |
| CI installs | Use the frozen lockfile flag |
What a scanner needs
A scanner that reads lockfiles needs a format it supports. Before you switch package managers, check that your scanning tool can read the lockfile you intend to commit, and run it once on the migrated project. Compare the package count and key versions with the previous lockfile. Differences are worth a look, since migration can change which versions are resolved.
Safeguard's SBOM and dependency scanning produces an inventory for your projects, and the free scan lets you check how your repository looks to it before you commit to a change.
Quick check
Is bun.lockb still supported?
The docs describe it as the older binary format and give a migration path to bun.lock. Plan to migrate rather than rely on it.
What if I have both package-lock.json and yarn.lock?
Bun migrates the first it finds in its documented order, which puts package-lock.json before yarn.lock, and warns about the others.
Sources
Last reviewed: 19 October 2026.
