Force npm update to update package.json (same as npm 6.x before)

[AcidSlide-Octal]

Hi there,

Is there a way (with npm 7.x) to save/update the package.json when doing an npm update?

I know before in npm 6.x this was the default, and there was --no-save if you don't want the package.json. I'm looking for the reverse of that in version 7.x.

Thanks in advance.

[dsnoeck]

I found interresting to have the package.json updated on npm update because it help to see what has been updated faster in Pull request. At least if we could have an option like --save to apply those changes, it would be great.

[AcidSlide-Octal]

exactly my point.. at least a way other devs know that the packages have been updated

[n1ngu]

For this concern, I'll usually parse the output of the npm list command, and format it for human review like

npm list --unicode=false --depth=9999 | tail -n +2  | sed  -e 's:^.*-- ::g' -e 's: deduped$::g' | grep -vE '^$' | sort | uniq > package-list.txt

It is cumbersome but it gives much more insight than the package.json and a cleaner view than the package-lock.json. You can also cut the dependency tree to the depth you are interested in. At depth 1 it becomes the resolution for your direct requirements only, but I like to watch the whole tree.

[MylesBorins]

pinging @npm/cli

[AcidSlide-Octal]

any update from @npm/cli ?

[AcidSlide-Octal]

Bumping issue/request.

[MylesBorins]

@AcidSlide-Octal I've prodded the team internally but you might want to try and open an issue over at https://github.com/npm/cli as well

[darcyclarke]

Today there's no way to do this for all deps easily in v7 - npm install is the right tool to update package.json but we've definitely heard from folks that they like the ergonomics of being able to update all their dep versions at the same time not just in package-lock.json (as you've noted); I've gone ahead & added this as a topic for our Open RFC Call today & can circle back if there is any outcomes from that discussion (ie. if we think a new proposal could be written that adds this functionality back into update or somehow into install, most likely through flags)

[IdeaNext]

@n1ngu I realize the logic behind this breaking change and of course a human modification in those situations is better than a robot , but isn't the caret sign (^) in package.json versions is the way to accomplish this ? If a human stated that a package should always be in it's latest version (^), wouldn't you expect it to be this way automatically?

[n1ngu]

@IdeaNext I fear that is a misunderstanding of the caret version specifier. With a caret you are not requiring the latest but a compatible version with whatever follows the caret according to semver. That is either from the smallest patch for that minor to whatever minor is published years after for the same major.

If you are distributing a library, you should not expect control over what your dependants resolve, and they will thank you for not being picky with your dependency specs (deduplicating their resolved dependencies). If you are distributing an app you should be deploying a shrinkwrap anyway so whatever is specified in the package.json is not an issue. 🤷‍♀️

[ruyadorno]

Please note that starting with [email protected] there's now an option to use npm update --save in order to save updated dependencies semver ranges back to the package.json file. It's also possible to have save=true in your .npmrc in order to make that the default behavior.

[matthewmayer]

i think there may be a bug in the new behavior regarding exact versions, see my comment at npm/cli#2704 (comment)

[matthewmayer]

@ruyadorno could you review npm/cli#2704 (comment) and see if this is intentional?

[AcidSlide-Octal]

@darcyclarke thanks for the letting me join the Open RFC session, i'll discuss in the thread in the next few days our main Use Case scenario (which is used currently in couple of our main projects)