[BUG] npm update does not save new versions in package.json #2704

saltire · 2021-02-15T18:22:39Z

Current Behavior:

When running npm update, packages are updated normally, package-lock.json is updated, but package.json is not. (npm install [package]@[version] does update package.json as expected.)

Expected Behavior:

The package.json file should be updated with the newly installed versions, as specified in the npm-update docs.

Steps To Reproduce:

npm update
Check package.json

Environment:

OS: Mac OS Big Sur
Node: 14.15.5
NPM: 7.5.4

The text was updated successfully, but these errors were encountered:

mjlehrke · 2021-02-16T03:53:13Z

I experienced this bug on Windows, NPM version 6.14.11. npm update failed to update package.json but a targeted install worked.

Interestingly, it seemed my global packages were also messed up around the same time this started. For instance, npm list -g --depth=0 would show the global packages but some of them would have messed up versions such as snyk@0. npm outdated would insist the package was outdated even after updating. Re-installing the packages or npm didn't fix.

I was able to fix this by completely uninstalling node, npm, Windows build tools, and chocolatey. I deleted all the related folders in my user folder, programs folder, %appdata%, %localappdata%, and %programdata%. A simple node/npm update wouldn't fix it, so something was messed up in one of those folders. After re-install of node/npm, package.json was updating as expected and the global packages issue was resolved.

CageFox · 2021-02-18T12:47:59Z

Same bug on windows 10 node v12.16.0
After npm upgrade versions in package.json not automatically updated

darcyclarke · 2021-02-19T19:38:28Z

@saltire sorry for the confusion, we need to update the docs to clarify that npm update will install & update the package-lock.json but not modify the spec defined in package.json; As you noted, you can still update that by running npm install <pkg>@<version> - this was a breaking change from v6, as that previously would modify package.json

CageFox · 2021-02-19T19:51:54Z

@saltire sorry for the confusion, we need to update the docs to clarify that npm update will install & update the package-lock.json but not modify the spec defined in package.json; As you noted, you can still update that by running npm install <pkg>@<version> - this was a breaking change from v6, as that previously would modify package.json

And what command can I use to update all packages, modifying specs in package.json?

jlchereau · 2021-02-24T09:05:02Z

@saltire sorry for the confusion, we need to update the docs to clarify that npm update will install & update the package-lock.json but not modify the spec defined in package.json; As you noted, you can still update that by running npm install <pkg>@<version> - this was a breaking change from v6, as that previously would modify package.json

There should be a better way than running npm install <pkg>@<version> on each package to update package.json. Maybe it is also time to introduce wildcards (or regular expression as in ncu), especially with scopes as in npm update @babel/*@7

mlippert · 2021-03-01T21:10:03Z

Since what I want to do is update the versions listed in package.json to the latest "Wanted" version and not the "Latest" version (as shown by npm outdated), this becomes a laborious process and for now I think I'm probably better off staying on npm v6 or downgrading to npm v6 (if using node v14).

I have my package versions set to "want" the latest non-breaking changes if semver is respected. I use the version in the package.json to help me know the version I actually last got and tested locally. When a non-breaking change actually breaks something, I update package.json to lock the previous version, report the issue and track the package for a fix.

I'm also wondering what the rationale for the breaking change was. There was already an option --no-save if you didn't want your package.json modified. Now there is no way to get the v6 behavior, other than one by one installing the latest specific wanted version of each package.

ym-project · 2021-03-08T08:39:55Z

I was extremely surprised when npm up command didn't update package.json file. I really hoped that it was a cli bug but @darcyclarke upset me :(

srknzl · 2021-03-19T18:19:31Z

@saltire sorry for the confusion, we need to update the docs to clarify that npm update will install & update the package-lock.json but not modify the spec defined in package.json; As you noted, you can still update that by running npm install <pkg>@<version> - this was a breaking change from v6, as that previously would modify package.json

Still not sure how to update all packages and change package.json

ym-project · 2021-03-20T03:34:08Z

Several people recommended me npm package for dependencies updates. Maybe it will be useful for somebody.

srknzl · 2021-03-20T05:07:58Z

Using a package to update packages is so weird. This is not the way it should be. By the way is there a way for the package to do "exactly" what npm update was doing before?

ym-project · 2021-03-20T05:57:49Z

Using a package to update packages is so weird. This is not the way it should be. By the way is there a way for the package to do "exactly" what npm update was doing before?

You can write your own script something like this
scripts/up.js

const {execSync} = require('child_process')
const packageName = process.argv[2]

const outdatedInfo = JSON.parse(execSync(`npm outdated -l --json ${packageName}`))

const packageCurrentVersion = outdatedInfo[packageName].current
const packageWantedVersion = outdatedInfo[packageName].wanted
const packageType = outdatedInfo[packageName].type
const isDev = packageType === 'devDependencies'

const updateInfo = execSync(`npm i ${isDev ? '-D' : ''} ${packageName}@${packageWantedVersion}`)

console.log(updateInfo.toString())

And then use node ./scripts/up webpack

I know it's not a good solution but why not?

ljharb · 2021-03-20T06:08:28Z

@srknzl npm is a package. It's really not weird.

srknzl · 2021-03-20T06:12:16Z

I mean why other 3rd party package if DeFacto standard is npm package

xavierfoucrier · 2021-05-21T11:26:29Z

@saltire sorry for the confusion, we need to update the docs to clarify that npm update will install & update the package-lock.json but not modify the spec defined in package.json; As you noted, you can still update that by running npm install <pkg>@<version> - this was a breaking change from v6, as that previously would modify package.json

This, is a serious breaking change / issue when migrating to v7, and this is not documented anywhere at this time: I just noticed that during migration.

The important questions now are:

what's the point to not updating the specs, like npm@6 did before?
is there a proper way to update the package.json file with npm@7?
did you plan to add a param to the CLI, or a new command to be able to do that in a near future?

Thanks for taking the time to give a clear answer to the community 😉

jarrodek · 2021-05-31T06:36:44Z

For now, I decided not to upgrade to npm >= 7. With this behavior, I lose track of what is happening with my project, which dependencies I am upgrading, and which still need to be upgraded (via the npm up command). I can't rely on checking changes to the lock file as this file is not meant to be read by humans. If I may suggest at least adding a CLI option to update the spec file when updating dependencies. This way we could have the previous behavior as an opt-in.

Regards.

yelworc · 2021-06-22T10:16:23Z

Stumbled upon this issue after upgrading npm, skimmed another issue thread and this one; at least two maintainers claim that this was an intentional breaking change, yet I can't find the rationale behind it (in fact, I wasn't even able to find any mention of it in the npm v7 changelogs at first glance).

I'm fine with adjusting my workflow, but at the moment I can't quite figure out how this new behavior of npm update is better than before (as others have pointed out, seeing incorrect versions package.json seems confusing at best to me).

arash-bizcover · 2021-07-18T10:46:52Z

@npm/cli-team please let us know, How the hell can we update all modules in package.json dependencies to their latest, from now on???

jlchereau · 2021-07-19T09:23:10Z

@npm/cli-team please let us know, How the hell can we update all modules in package.json dependencies to their latest, from now on???

For now I have not found any alternative to npm i -g npm-check-updates && ncu -u. They should really implement this in npm@7.

ljharb · 2021-07-19T15:02:11Z

There’s also,npx salita

arash-bizcover · 2021-07-19T22:15:04Z

NPM Version 7 feels like if some .NET lovers have sneaked into the npm development team and trying to ruin the JS development experience.

n1ngu · 2021-07-26T12:52:36Z

And what command can I use to update all packages, modifying specs in package.json?

@CageFox @arash-bizcover the fact is npm@6 never udpated package.json beyond the specs defined within itself. It might be controversial because it is a breaking change with npm@6, but there is little point in automatically evolving this file.

If you distributed an app, you should be distributing a shrinkwarp file. If you distributed a library, you'd only bump the specs in package.json when manually conducting a major upgrade.

See also #708 (comment) and npm/feedback#270

ljharb · 2021-11-04T06:32:49Z

and yet, it’s a range.

matthewmayer · 2021-11-04T06:49:43Z

Sorry I don't understand. How is "millify": "3.5.2" a range? Doesn't that mean 3.5.2 exactly?

ljharb · 2021-11-04T14:43:13Z

No, i mean “=3.5.2” is a range - one that contains exactly one version.

jginsburgn · 2022-01-04T05:12:25Z

Will this get addressed?

StefanNedelchev · 2022-01-05T18:58:19Z

I recently updated to npm 8.3.0 and I received the "pleasant" surprise just like all of you. Since it seems that nothing has changed for more than an year, I'm really worried and I wonder if I should revert back to npm v6 or keep up with v8. If there was any hint that this behavior will be restored or at least introduced as an optional argument, I would stick to v8.

Previously `npm update` was not respecting the `save` option, it would be impossible for users to use `npm update` and automatically update their `package.json` files. This fixes it by adding extra steps on `Arborist.reify._saveIdealTree` to read direct dependencies of any `package.json` and update them as needed when reifying using the `update` and `save` options. Fixes: npm#708 Fixes: npm#2704 Relates to: npm/feedback#270

n1ngu · 2022-01-10T16:12:31Z

@jginsburgn @hardmaster92 Sorry but, as critical as this looks for you, could you please read the whole thread and the linked discussions before commenting that?

Previously `npm update` was not respecting the `save` option, it would be impossible for users to use `npm update` and automatically update their `package.json` files. This fixes it by adding extra steps on `Arborist.reify._saveIdealTree` to read direct dependencies of any `package.json` and update them as needed when reifying using the `update` and `save` options. Fixes: npm#708 Fixes: npm#2704 Relates to: npm/feedback#270

ruyadorno · 2022-01-20T22:28:44Z

The team has decided that fixing usage of npm update --save was the best way moving forwards 😊 it enables saving dependency ranges to package.json as expected. It's also worth noticing that you can also just set save=true in a .npmrc file in case you want that to be the default behavior..

npm@8.3.2 is out now with the fix 🎉

CageFox · 2022-01-20T22:36:36Z

It seems the issue resolved and now we can move to actual npm too

xavierfoucrier · 2022-01-20T22:52:31Z

@ruyadorno Great news! Big thanks for that 🎉

sla100 · 2022-01-21T05:20:25Z

.npmrc of 2022:

global-style=true
engine-strict=true
legacy-peer-deps=true
lockfile-version=3
save=true

ljharb · 2022-01-21T05:51:24Z

@sla100 legacy-peer-deps should be avoided; that's just papering over your invalid dependency graph, and since engines is purely advisory, engine-strict is going to break just as often as it helps you. I've never heard of global-style, and save=true is the default.

matthewmayer · 2022-01-21T06:13:08Z

and save=true is the default.

Is it? The comments above suggest save=false is the default in 8.3.2?

ljharb · 2022-01-21T06:17:42Z

@matthewmayer it's the default for update, but i believe --save on the command line only will overwrite that for update. save=true is already the default for everything else.

sla100 · 2022-01-21T06:25:52Z

I've never heard of global-style

This is a best mode for the project. The first level of node_modules contains only first-level dependencies.

ljharb · 2022-01-21T06:27:54Z

That will break a lot of setups (the same ones yarn pnp and pnpm break). Packages expect the hoisting npm does.

matthewmayer · 2022-01-21T10:58:14Z

npm update --save in npm@8.3.2 works differently to npm update in npm@6 when specifying an exact version

For example if you run npm install --save-exact cron@1.8.0

Then your package.json will look like this:

"cron": "1.8.0"

if you then run on npm@6
npm update

nothing is changed

but if you then run on npm@8.3.2

npm update --save

package.json is updated to

"cron": "^1.8.0"

and then if you run npm update --save again package.json is updated to

"cron": "^1.8.2"

davidspiess · 2022-01-24T18:36:32Z

I ran into the same issue as well. This could potentially break some production apps, since pinning a dependency to a specific version is rather common and can slip through code reviews quite easily.

StefanNedelchev · 2022-01-25T07:18:24Z

I ran into the same issue as well. This could potentially break some production apps, since pinning a dependency to a specific version is rather common and can slip through code reviews quite easily.

Agree for the code reviews. Much easier to review package.json rather than package-lock.json.

matthewmayer · 2022-01-29T08:40:47Z

npm update --save in npm@8.3.2 works differently to npm update in npm@6 when specifying an exact version

For example if you run npm install --save-exact cron@1.8.0

Then your package.json will look like this:

"cron": "1.8.0"

if you then run on npm@6 npm update

nothing is changed

but if you then run on npm@8.3.2

npm update --save

package.json is updated to

"cron": "^1.8.0"

and then if you run npm update --save again package.json is updated to

"cron": "^1.8.2"

This was fixed in npm@8.4.0, thanks @ruyadorno !

aplotor · 2022-08-13T23:16:38Z

v=8.11.0 npm update --save is not updating package.json for me

skysantoroa · 2022-08-22T12:34:35Z

v=8.11.0 npm update --save is not updating package.json for me

Same for version 8.5.5, node 16, Ubuntu 22

ljharb · 2022-08-22T14:38:22Z

There’s no point in trying a non-latest version of npm - if you’re still having problems with the latest version, please file a new issue.

amycheng2958 · 2022-09-09T07:03:32Z

v=8.11.0 npm update --save is not updating package.json for me

Same for version 8.5.5, node 16, Ubuntu 22

Same for version 8.5.0, node 16, macos monterey

lukekarrys · 2022-11-12T22:45:13Z

Please open a new issue for any bugs or regressions with update --save.

saltire added Bug thing that needs fixing Needs Triage needs review for next steps Release 7.x work is associated with a specific npm 7 release labels Feb 15, 2021

darcyclarke removed the Needs Triage needs review for next steps label Feb 19, 2021

darcyclarke added pr: needs documentation pull request requires docs before merging Priority 2 secondary priority issue and removed Bug thing that needs fixing labels Feb 19, 2021

srknzl mentioned this issue Mar 19, 2021

Update dependencies hazelcast/hazelcast-nodejs-client#825

Merged

arash-bizcover mentioned this issue Jul 18, 2021

[BUG] npm update not updating package.json #708

Closed

ruyadorno mentioned this issue Jan 7, 2022

fix: npm update --save #4223

Merged

lukekarrys closed this as completed in cfd59b8 Jan 20, 2022

matthewmayer mentioned this issue Jan 26, 2022

npm update --save in npm@8.3.2 does not respect exact versions #4329

Closed

[BUG] npm update does not save new versions in package.json #2704

[BUG] npm update does not save new versions in package.json #2704

Comments

saltire commented Feb 15, 2021

Current Behavior:

Expected Behavior:

Steps To Reproduce:

Environment:

mjlehrke commented Feb 16, 2021

CageFox commented Feb 18, 2021

darcyclarke commented Feb 19, 2021

CageFox commented Feb 19, 2021 • edited Loading

jlchereau commented Feb 24, 2021 • edited Loading

mlippert commented Mar 1, 2021

ym-project commented Mar 8, 2021

srknzl commented Mar 19, 2021

ym-project commented Mar 20, 2021

srknzl commented Mar 20, 2021

ym-project commented Mar 20, 2021

ljharb commented Mar 20, 2021

srknzl commented Mar 20, 2021

xavierfoucrier commented May 21, 2021

jarrodek commented May 31, 2021

yelworc commented Jun 22, 2021

arash-bizcover commented Jul 18, 2021 • edited Loading

jlchereau commented Jul 19, 2021

ljharb commented Jul 19, 2021

arash-bizcover commented Jul 19, 2021 • edited Loading

n1ngu commented Jul 26, 2021 • edited Loading

ljharb commented Nov 4, 2021

matthewmayer commented Nov 4, 2021

ljharb commented Nov 4, 2021

jginsburgn commented Jan 4, 2022

StefanNedelchev commented Jan 5, 2022

n1ngu commented Jan 10, 2022

ruyadorno commented Jan 20, 2022

CageFox commented Jan 20, 2022

xavierfoucrier commented Jan 20, 2022

sla100 commented Jan 21, 2022

ljharb commented Jan 21, 2022

matthewmayer commented Jan 21, 2022

ljharb commented Jan 21, 2022

sla100 commented Jan 21, 2022

ljharb commented Jan 21, 2022

matthewmayer commented Jan 21, 2022 • edited Loading

davidspiess commented Jan 24, 2022

StefanNedelchev commented Jan 25, 2022

matthewmayer commented Jan 29, 2022

aplotor commented Aug 13, 2022

skysantoroa commented Aug 22, 2022

ljharb commented Aug 22, 2022

amycheng2958 commented Sep 9, 2022

lukekarrys commented Nov 12, 2022

CageFox commented Feb 19, 2021 •

edited

Loading

jlchereau commented Feb 24, 2021 •

edited

Loading

arash-bizcover commented Jul 18, 2021 •

edited

Loading

arash-bizcover commented Jul 19, 2021 •

edited

Loading

n1ngu commented Jul 26, 2021 •

edited

Loading

matthewmayer commented Jan 21, 2022 •

edited

Loading