bun
bun copied to clipboard
oven-sh
Have `bun install` respect/translate lockfiles from other package managers
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?
@patricio-ir did you ever find a solution to this / @Electroid any progress on this from the bun side?
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.
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.
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.
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.
I think it is one of the major issues to solve in order to reduce migration pain.
+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.
+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 😢
@Jarred-Sumner is it possible to get an official response on this issue? Like others, this is preventing me from migrating an existing prod API.
We will add support for migrating from an existing lockfile to Bun without changing resolved versions
On Thu, Sep 21, 2023 at 2:11 AM Isaac Hinman @.***> wrote:
@Jarred-Sumner https://github.com/Jarred-Sumner is it possible to get an official response on this issue? Like others, this is preventing me from migrating an existing prod API.
— Reply to this email directly, view it on GitHub https://github.com/oven-sh/bun/issues/1751#issuecomment-1729169376, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFNGSZFKIO7HP2G5V43LJ3X3QACNANCNFSM6AAAAAATVZUVA4 . You are receiving this because you were mentioned.Message ID: @.***>
from now we can migrate with remove caret from package.json ^ to make version strict.
example "next": "^13.4.4", to be "next": "13.4.4",
@GeuntaBuwono Pinning deps in your package.json won't handle transitive deps. Could work for some projects but is not foolproof and is not a first-class migration flow.
@GeuntaBuwono I don’t think that works, there’s all the other nested dependencies that are tracked in the yarn.lock/package-lock.json that would receive different versions.
In Bun v1.0.5, @paperdave added support for importing from a package-lock.json into a bun.lockb
https://github.com/oven-sh/bun/pull/6352
I'm going to close this and mark it as completed, however we will also add support for importing yarn.lock: https://github.com/oven-sh/bun/issues/6409
Once Bun v1.0.5 lands (or bun upgrade --canary once it finishes compiling), you can either run bun install or run bun pm migrate and it'll automatically detect the package-lock.json file and convert it in-place to a bun.lockb.
In the meantime, something like synp should fill the gap for yarn users wanting to migrate.
synp fails with workspaces =(
