New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Have bun install
respect/translate lockfiles from other package managers
#1751
Comments
@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:
So I think an intermediate solution could be to support translation of only v1 (I'm not sure how well the |
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 If there was a way to somehow convert a |
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 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
|
+1 |
+1
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
<#1751 (comment)>, 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 |
@GeuntaBuwono Pinning deps in your |
@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. |
@Jarred-Sumner is there a proposed timeline for this project? |
In Bun v1.0.5, @paperdave added support for importing from a I'm going to close this and mark it as completed, however we will also add support for importing yarn.lock: #6409 Once Bun v1.0.5 lands (or |
In the meantime, something like synp should fill the gap for yarn users wanting to migrate. |
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 bynpm
(package-lock.json
) oryarn
(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
formatWhat alternatives have you considered?
Writing a separate lockfile translator that can convert
package-lock.json
s andyarn.lock
s into abun.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?The text was updated successfully, but these errors were encountered: