bun update does not update package.json

[Dhruv-Garg79]

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

[Hanaasagi]

Related to

• bun update doesn't update version number in package.json #5512
• bun update --save doesn't save to package.json #4312

[sindelio]

+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

[voltuer]

any ETA for the fix?

[Barzi-Ahmed]

I have this issue as well.
Using Bun 1.0.22.
Windows WSL.

[Barzi-Ahmed]

1+ priority pls.

[sindelio]

+1 priority

[dreyfus92]

+1 priority

[drinkius]

Also agree on priority, really stopping me from moving to bun on some projects

[jorismak]

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?

[winstxnhdw]

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.

[malininss]

Have the same issue. We need a command for updating versions in package.json too

[jorismak]

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?

[winstxnhdw]

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.

[jorismak]

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 list or pnpm list are 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 a bun 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 for bun 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.

[winstxnhdw]

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.

[federicofazzeri]

1+ priority pls.

[voltuer]

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

[jorismak]

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 <#5856 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALMD2DRRAD3PY33PZKUDTGDYQZ5PVAVCNFSM6AAAAAA5BJIMLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGY2TKMZWGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[sovetski]

Any update?

[voltuer]

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

[adiologydev]

This is such an essential tooling feature. Let's prioritize this a bit higher, please?

[jizhi0v0]

Still exists on 1.0.33.

[Jarred-Sumner]

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.

[jizhi0v0]

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!

[Confucian-e]

Still exists on 1.0.33.

+1 priority

[garyellow]

+1 priority
really need it

[itsjoeoui]

+1 on this

[kingkong404]

+1 priority

[HassanDomeDenea]

+1

[tobycm]

For a workaround, bun x taze -w works for me in the mean time

[sindelio]

Thx for the workaround!

[vladstudio]

For a workaround, bun x taze -w works for me in the mean time

@tobycm wow, are there any docs I could read about this command?

[vladstudio]

@tobycm nevermind, I found it's an NPM package: https://www.npmjs.com/package/taze

There's also https://www.npmjs.com/package/npm-check-updates which says it's bun compatible, so you can simply ncu -u .

[XavierGeerinck]

I just wanted to also +1 this. We are using bun at the moment through turbo and honestly, getting a Docker container ready and using it dev wise has been the most painful experience ever.

[stabildev]

please fix this

[billgo]

This issue still exists in version v1.1.3

[Dhruv-Garg79]

yes, it still exists, and now it is not even updating dependencies let alone updating the package.json. Just updated to 1.1.3

[touhidurrr]

As of 1.1.4, I am facing problems with:

1. bun update
2. bun update --latest
3. bun update -f
4. bun update -f --latest

None of these commands update package.json.

[sohanemon]

The issue still persists in version 1.1.4 of Bun. It has been a considerable amount of time, and the inconvenience of manually writing the package.json file is quite frustrating.

[ThatOneCalculator]

For now you can use bunx taze

[budivoogt]

bunx taze -w has been a good workaround.

I agree it's annoying there's no response after calling bun update that says you need to add a --save flag to update package.json, and that flag doesn't even work for me.

Struggling to build a Docker image with Bun too.

[Jarred-Sumner]

This will be fixed in Bun v1.1.11 (#11340)

[jgentes]

This will be fixed in Bun v1.1.11 (#11340)

Thank you so much for making it save changes by default! That's the right call, Bun shouldn't just follow in the footsteps of what other package managers have done.

[browner12]

I'm sorry, but this makes no sense to me. Composer does not edit your composer.json file when performing updates. NPM does not edit your package.json file when performing updates.

Your "json" file should be for defining what version constraints you want, and your lock file should be for defining what version you have. Changes to the "json" file should be made when you explicitly want to change the constraints, not to sync them up with your lock file on every update.

While it probably won't negatively impact a majority of apps, IMO it just creates a lot of unnecessary Git changes.

If people truly need this feature, I would argue that it should be behind a feature flag, and the default should be to not edit the package.json file.

For context, I am a PHP developer that uses package.json just to install a handful of devDependencies, so maybe there's some use case I don't understand here, but that's my 2 cents.

[touhidurrr]

@browner12, i would argue that package-lock.json is a generated file which people should not mess with. package manager uses it to manage your packages and people should leave it at that. when you use bun update, you expect to update packages to their latest version, so this change should be reflected on package.json. I thought this was the whole point of an update command. Otherwise, what should it do and how should it behave?
I don't think any other behavior of this command is something that is naturally expected.

[browner12]

correct, your lock file (package-lock.json, or bun.lockb, or whatever) is generated, and should never be manually updated.

bun update should read your package.json file, evaluate the version constraints, determine and download the latest version that matches your constraints, and write the actual version it downloaded to your lock file. All without touching your package.json file.

This is how both NPM and Composer have behaved for years.

[malininss]

@browner12 in your opinion, what are the benefits of the behavior you explained? And if I want to update my packages, what are the disadvantages of updating both the package.json and the lock file?

[jamesatalternateaddress]

bun update should read your package.json file, evaluate the version constraints, determine and download the latest version that matches your constraints, and write the actual version it downloaded to your lock file. All without touching your package.json file.

@browner12 that's what npm install and bun install do.

This is how both NPM and Composer have behaved for years.

This is a logical fallacy.

[sindelio]

The problem here is that IF YOU ARE USING RANGES in your pachage.json deps, then you can end up in a scenario where you can't be certain of the specific version you have. Imagine you need to downgrade due to a security issue or a bug, how would you know what version you actually have? Looking into the lock file bun.lockb is a no no.
My suggestion for those who are using and loving Bun is to consider not using ranges on your package.json deps, and instead specify the exact versions.

For example:

"dependencies": {
    "express": "5.0.0-beta.3",
  },

Instead of:

"dependencies": {
    "express": "^5",
  },

When updating a package, you should explicitly mention the dep version. Then Bun will update the package.json (by default it uses --save now), and you have total clarity on what version you have.

[browner12]

@malininss I would say there are two disadvantages to having bun update edit the package.json file.

• Git diff noise. It's making an unnecessary change that adds more to your history. Minor, yes, but still relevant.
• you lose the ability (or make it more difficult) to find intentional changes to the version constraints. If bun update does not change the package.json file, every commit was an intentional change to the version constraints. If you allow it to update the package.json file, you have a bunch of commits that effectively don't change the version constraints, as the written version already falls within the previous constrains.

I point to Composer and NPM not to simply follow what came before us, but to lay precedent from 2 wildly successful projects where the behavior I've discussed is preferred.

@sindelio by specifying an exact version you've now effectively just neutered your package manager, and have to do all version management yourself. Half of the point of dependency management is to use ranges and semantic versioning to get non breaking package updates.

NPM had a command called npm list which printed out all of the currently installed versions from your lock file. Bun should probably have this as well.

[touhidurrr]

@browner12, i don't see the point. As mentioned prior, what you want is already done by bun install. And bun update is intentional changes that you would like to commit. Not everyone likes their packages update and just keep using whatever version they started the project with, and those that do, they do it very intentionally.

Lastly, why does this command even exist? Bun tries to solve the problems node developers have always have and tries to package the solution with bun so that you dont need any additional dependencies for that. Without the existance of an update command, the only way to update packages would be updating version numbers by hand one by one or installing a dependency that does that for you. Both ways, it is your intention to update package.json. It exists because the demand for it exists which is evident from how active this issue (and multiple other issues also pointing out many issues with this one command which is fortunately fixed now). If you have no demand for this command or don't think it is a good practice, how about simply not using the command to begin with? I believe there is something like --no-save flag also to achive the result you want. Saving is the default behaviour simply because everyone expects it to be.

In the end, I would say that I find no good reason to believe that the current default behaviour of the update command should be changed. bun update solves a problem that was shared by many developers on the JavaScript ecosystem, as evident by the activity on the issues regarding this command. Also, the current default behaviour is also what most developers expect it to be (which is what default behaviours should be). So, it is perfect in my opinion.

[sindelio]

@browner12 I use the package manager to download and deps, allocate their code neatly and deduplicate code if needed. Updating a package is very deliberate to me, because it can break a project in many ways. So I don't want a command that leaves me with doubt on the version of a dep in the project. For instance, every time the deps are updated, I run tests against them to make sure everything is running.
If you want to use a range in your deps, and have the package manager download non breaking changes, that's fine as well. To each their own, and this behavior can be achieved with the --no-save flag. I think the default behavior should lean towards clarity, with the --save flag active by default.