bun
bun copied to clipboard
oven-sh
bun update does not update package.json
What version of Bun is running?
1.0.2
What platform is your computer?
Darwin 22.6.0 arm64 arm
What steps can reproduce the bug?
run bun update in any node project with bun as a package manager
What is the expected behavior?
when we run bun update, it should update all the dependencies in the package.json.
What do you see instead?
when we run bun update, it shows updated dependencies in the terminal and indentation of package.json changes without change to the dependency version
Additional information
No response
Related to
- https://github.com/oven-sh/bun/issues/5512
- https://github.com/oven-sh/bun/issues/4312
+1 for this task. I am using bun in production already, just had to manually check the package.json for outdated lines, even though the modules are acutally updated by bun
Also agree on priority, really stopping me from moving to bun on some projects
But is this wanted behaviour ? Package.json has the version constraints , and an update will update them within those constraints. With npm, the only thing that's changing is the lock file.
I don't get what should change in the package.json when running bun update?
But is this wanted behaviour ? Package.json has the version constraints , and an update will update them within those constraints. With npm, the only thing that's changing is the lock file.
I don't get what should change in the package.json when running bun update?
If you've used yarn before, the equivalent command would update these constraints to the latest. It's a nice QoL helper that ensures that your project is on the latest version for every dependency.
Have the same issue. We need a command for updating versions in package.json too
Sounds confusing, and kinda defeating of the whole "version constraints and lockfile" idea. I'm sure it has its place, not arguing against that.
Just surprised. It's not what almost every other package manager does, in JS or other languages. "Install" follows the lockfile if available, or creates/amends it. "Update" takes the latest versions available, within the constraints mentioned in de package.json.
Ignoring the version constraints in package.json is not what npm does, pnpm does and in other languages. And sounds confusion , why else are the constraints there? I must be missing something.
If you dont want version constraints and want to take new major versions or whatever, just name them "*" or something in package.json?
It’s not confusing. People want to see what version of the package they are on without sieving through the lockfiles. It also makes it a lot easier to freeze the dependency when we eventually hit an issue with the latest version.
Btw pnpm update —latest exists too.
So, I'm reading if yarn really does something different to other package managers.
And from what I see from the docs there isn't a yarn update. It was first yarn upgrade and it's now yarn up.
So, hear me out. There is a reason - I think - that yarn didn't choose the same update command name. They knew that if they have different semantics or the command does things differently, it shouldn't have the same name.
I'm not saying that the functionality you people want shouldn't exist. Not at all. But - the pnpm command above is a good example - it should be a flag or a different command, not just 'update'. Because there is a different expectation compared to saying 'bun update'.
If you name the command the same as npm update, it should behave pretty much the same. And every kind of extra functionality should be a flag or a different command name.
The package-manager of course doesn't have to be an exact clone from the npm functionality, that is for the bun people to decide.
This might be of course my bubble, but I would not expect bun - or any other package manager - to adjust the main JSON package file from running update without anything extra. And I guess if way more people expected that, there would be more traffic to this topic.
So… in my humble opinion, just from the convention set for tools like npm, pnpm, composer and probably others… the update command should not touch package.json, only the lock file. Make a different command or add a flag if different behaviour is changed, like locking things in place (but you do you really do that for all dependencies listed??) or updating the version constraints to take later versions if they are available (and then testing later if they work or code needs changing).
People want to see what version of the package they are on without sieving through the lockfiles. That's what
npm listorpnpm listare for. Bun choose to make the lock file binary even (but in a way it can dump it human-readable quickly). People might wait for bun to have abun list(it's reserved, so it might come). If you prefer to use the package.json file differently, then you do you. I'm not telling anyone how to use tools or not. But I do advise the bun team to use a flag or different command for that functionality and not make it the default behaviour forbun update.
The description for bun update was at one point in time "Update outdated dependencies and update package.json", but the "and update package.json" part has been removed.
From what's currently in the bun update --help output, it IS confusing that it lists --save as being active by default and listed as 'Save to package.json'. But that is more used for bun install and bun add, that if you add a dependency it will update package.json. (From the old --save and --save-dev npm flags).
So. there is some information in the bun help output that contradicts the current behaviour. So I guess it's up to the bun team to decide what they actually want the command to do, and then fix the --help output or update the behaviour ;).
But I know a lot of people will be scratching their heads when bun update suddenly starts making changes to package.json and ignoring the version constraints in there.
I agree that it should be a flag like bun update --latest as well. Unfortunately, right now bun update --save doesn't work as expected either.
this project should never had released a 1.0 version, it totally lacks of real-world testing, i see a lot of issues in github from people who can't achieve basic Node/npm/pnpm things and, just like this one, are completely ignored even after 4 months
The team has a different road map compared to what you find important. It happens . Jared already mentioned he thinks this is important, they just have different things to do first, for whatever reason. Accept that, please .
And like is mentioned here (by me? Maybe others ) is that updating the version constraints file while doing update isn't standard at all .
On Sun, Jan 28, 2024, 17:40 sebolio @.***> wrote:
this project should never had released a 1.0 version, it totally lacks of real-world testing, i see a lot of issues in github from people who can't achieve basic Node/npm/pnpm things and, just like this one, are completely ignored even after 4 months
— Reply to this email directly, view it on GitHub https://github.com/oven-sh/bun/issues/5856#issuecomment-1913655364, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALMD2DRRAD3PY33PZKUDTGDYQZ5PVAVCNFSM6AAAAAA5BJIMLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGY2TKMZWGQ . You are receiving this because you commented.Message ID: @.***>
And like is mentioned here (by me? Maybe others ) is that updating the version constraints file while doing update isn't standard at all .
then add an "upgrade" command like other managers do? come on, it's been 6 months
This is such an essential tooling feature. Let's prioritize this a bit higher, please?
We will fix this a little bit after v1.1. The team is focused on shipping Windows support right now, and we're so close.
We will fix this a little bit after v1.1. The team is focused on shipping Windows support right now, and we're so close.
Good job!
I would argue that updating a package in the bun lockfile and not reflecting that in package.json is non-intuitive, as it effectively creates a mismatch between the codified system of record (what you think is running) and what's actually running.
If I run bun update jsdom I would expect it to update that package to the latest version and save that version to my package manifest.
If Bun does require a --save flag, please include that info in the response after running the update command so people know that the updates were not saved as they probably expected they would be.
Upvoting this one more time! I'm already running Bun in production, having to keep track of the package versions is not a great developer experience.
