Have `bun install` respect/translate lockfiles from other package managers

[trcio]

What is the problem this feature would solve?

When trying to use bun install on an existing codebase, it is likely there would also exist a lock file generated by npm (package-lock.json) or yarn (yarn.lock).
Right now, running bun install on a codebase like this results in a potentially different dependency tree being resolved and installed.
To maintain consistent behavior in the application itself and to sweeten the deal when adopting bun, bun install should respect the dependency tree that has been previously resolved.

What is the feature you are proposing to solve the problem?

When running bun install for the first time on a codebase, it should check for the existence of various lockfiles.
If there already exists a bun.lockb file, no further steps are required.
If no bun.lockb is found, start checking for the other lock file types.
If any of those are found, bun should be able to parse it correctly and install the dependencies described by it - it can then save the tree in the bun.lockb format

What alternatives have you considered?

Writing a separate lockfile translator that can convert package-lock.jsons and yarn.locks into a bun.lockb format.
Certainly could prove useful for existing codebases that want to benefit from the offerings of bun

Integrating this as a step in the logic of bun install seems like the best route?

[claycoleman]

@patricio-ir did you ever find a solution to this / @Electroid any progress on this from the bun side?

[Jarred-Sumner]

We should opt for translating the lockfile to ease migration, but it will be a little tricky to get right given the various formats. Maybe we need to expose a lockfile format to JS and then use an existing npm package to read from multiple lockfile formats and translate into one. Since this would be a one-off script, it probably would be fine to write in JS.

[jakeboone02]

Just some additional info about this:

yarn import (from Yarn v1) can take a populated node_modules folder and generate a v1 yarn.lock file. It will use a package-lock.json file if it exists, but falls back to the actual installation in node_modules.

So I think an intermediate solution could be to support translation of only v1 yarn.lock files to bun.lockb. Supporting other formats like Yarn v2+ or pnpm could come later.

(I'm not sure how well the yarn import would work when used on a pnpm-managed repo, but if it works well this could be a good first step.)

I would also like the ability to generate a npm-shrinkwrap.json or package-lock.json file from the bun.lockdb file. That would allow me to run npm audit or use frameworks like CDK that does not use the bun.lockdb file.

[dougludlow]

This is one of the main things holding us back from adopting bun at this time. We have a fairly large monorepo and are currently using yarn (v1). We are wary of upgrading all versions of all dependencies, which effectively happens when running bun install for the first time in our project because bun doesn’t honor our existing yarn.lock yet.

If there was a way to somehow convert a yarn.lock or package-lock.json to a bun.lockb, I believe large, pre-existing projects like ours would be more apt to migrate to and adopt bun.

[chrisheninger]

Also just gave this a try for a couple of hours– couldn't finish the migration in my project from yarn berry -> bun because of types package versioning shenanigans and bun install not reading from yarn.lock.

A tool to migrate the yarn.lock file would be splendid– I'm likely going to need to bite the bullet, do all the different typescript-package-related upgrades, then give bun another shot as a drop-in replacement.

[cawabunga]

I think it is one of the major issues to solve in order to reduce migration pain.

[raimondlume]

+1 to above

For reference, I liked the ease of migrating to pnpm to yarn (v1) thanks to their pnpm import utility.

bun install --yarn seems to be a thing, a reverse of this (yarn.lock to bun.lockb) would be a nice first option for us.

[nickngafook]

+1
This is preventing full migration to bun :(

[maurolemos]

+1
No doubt is fast

bun install  0.02s user 7.43s system 75% cpu 9.919 total
yarn install  30.25s user 54.96s system 248% cpu 34.287 total

but not respecting the existing lock file versions makes it unusable 😢