Skip to content
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

Is it possible to upgrade the "npm" in the package.json #423

Closed
zrx8269 opened this issue Feb 26, 2018 · 9 comments
Closed

Is it possible to upgrade the "npm" in the package.json #423

zrx8269 opened this issue Feb 26, 2018 · 9 comments
Milestone

Comments

@zrx8269
Copy link

zrx8269 commented Feb 26, 2018

  • node version: v6.10.2
  • npm version: v3.10.10
  • npm-check-updates version: 2.14.0

After install the "npm-check-updates" in my project, it will also install its dependencies, but the version of "qs" module under "npm" is too low for my security check, is it possible for you to update the "npm" version in package.json?
Thanks very much.

@raineorshine
Copy link
Owner

raineorshine commented Feb 26, 2018 via email

@zrx8269
Copy link
Author

zrx8269 commented Feb 27, 2018

Thanks for your reply, but the same error occurs under the "npmi" package.

@raineorshine
Copy link
Owner

raineorshine commented Feb 28, 2018

Ah, good catch. Try now:

npm uninstall -g npm-check-updates
npm install -g npm-check-updates@v3-alpha

@raineorshine raineorshine added this to the 3.0.0 milestone Feb 28, 2018
@billyjanitsch
Copy link
Contributor

Hi @raineorshine! Thanks for your work maintaining this library! 😊

Just to let you know: prerelease versions should be formatted like 3.0.0-alpha.1. The . between alpha and 1 is necessary for npm to handle semver/sorting correctly.

You might also consider tagging it as next rather than v3-alpha (not required, just an npm convention for prereleases). You can run:

$ npm dist-tag add npm-check-updates@3.0.0-alpha1 next
$ npm dist-tag rm npm-check-updates v3-alpha

In any case, I'm excited to play with this version!

@raineorshine
Copy link
Owner

Hi @billyjanitsch! Thank you. I must be getting rusty on my semver!

In hindsight I should have done the next tag. Glad it's fixable!

@raineorshine
Copy link
Owner

@billyjanitsch I'm getting a 401 on the delete. I've logged out and back in again so I seem to be logged in correctly. Any ideas?

@billyjanitsch
Copy link
Contributor

That's odd. The man page says npm dist-tag rm <pkg> <tag>. Maybe v3-alpha needs to be quoted because of the dash?

Anyway, thanks for fixing up the versioning! :)

abernix added a commit to apollographql/apollo-server that referenced this issue Apr 11, 2018
It appears that the intention of including `npm-check-updates` in this
repository was to provide an easy way to update dependent packages from the
console.  This was originally introduced in [Ref 0].

Unfortunately, the `npm-check-updates` package has an explicit dependency on
`npm@3`, which means that it includes the entire `npm` in its
`node_modules`.

I originally observed this when analyzing the test failures in [Ref 1] and
[Ref 2] which indicated (in its npm error) that the npm version was v3.10.10.

The explanation for this is relatively straight-forward: Older versions of
npm uses an nested tree of `node_modules` directories while newer versions
hoist `node_modules` (i.e. flatten) to the highest location possible and
only nesting dependencies to meet conflicting version constraints.

Unfortunately, that means that once `npm@3` was installed by the newer
`npm@5` as a dependency of `npm-check-updates`, it was hoisted to the
top-level `node_modules` directory, exposing `npm@3` to `npm-scripts` which
directly call `npm` commands on the nested packages, as is done on this
monorepo (with, for example the `postinstall` script which runs `npm run
compile` in each of the server middleware packages). :face_palm:

Overall, this package doesn't seem to provide enough value for us to
continue to include it, especially since we have Renovate - coupled with the
same information being available from `npm outdated` and `npm update`
commands.  I'm not sure why we would want to install newer versions than our
"package.json" allows.

Futhermore, looking at the issue tracker on `npm-check-updates`, I'm
assuming this is the reason I've seen "`dezalgo`" install errors [Ref 3] on
this repository recently and _possibly_ even a bizarrely corrupted npm cache
I encountered recently (though admittedly, that could be a stretch).

See also: [Ref 4].

[Ref 0]: d7ca07f7
[Ref 1]: https://circleci.com/gh/apollographql/apollo-server/1915
[Ref 2]: https://app.netlify.com/sites/apollo-server-docs/deploys/5acdd3b7
[Ref 3]: raineorshine/npm-check-updates#420
[Ref 4]: raineorshine/npm-check-updates#423
abernix added a commit to apollographql/apollo-server that referenced this issue Apr 17, 2018
It appears that the intention of including `npm-check-updates` in this
repository was to provide an easy way to update dependent packages from the
console.  This was originally introduced in [Ref 0].

Unfortunately, the `npm-check-updates` package has an explicit dependency on
`npm@3`, which means that it includes the entire `npm` in its
`node_modules`.

I originally observed this when analyzing the test failures in [Ref 1] and
[Ref 2] which indicated (in its npm error) that the npm version was v3.10.10.

The explanation for this is relatively straight-forward: Older versions of
npm uses an nested tree of `node_modules` directories while newer versions
hoist `node_modules` (i.e. flatten) to the highest location possible and
only nesting dependencies to meet conflicting version constraints.

Unfortunately, that means that once `npm@3` was installed by the newer
`npm@5` as a dependency of `npm-check-updates`, it was hoisted to the
top-level `node_modules` directory, exposing `npm@3` to `npm-scripts` which
directly call `npm` commands on the nested packages, as is done on this
monorepo (with, for example the `postinstall` script which runs `npm run
compile` in each of the server middleware packages). :face_palm:

Overall, this package doesn't seem to provide enough value for us to
continue to include it, especially since we have Renovate - coupled with the
same information being available from `npm outdated` and `npm update`
commands.  I'm not sure why we would want to install newer versions than our
"package.json" allows.

Futhermore, looking at the issue tracker on `npm-check-updates`, I'm
assuming this is the reason I've seen "`dezalgo`" install errors [Ref 3] on
this repository recently and _possibly_ even a bizarrely corrupted npm cache
I encountered recently (though admittedly, that could be a stretch).

See also: [Ref 4].

[Ref 0]: d7ca07f7
[Ref 1]: https://circleci.com/gh/apollographql/apollo-server/1915
[Ref 2]: https://app.netlify.com/sites/apollo-server-docs/deploys/5acdd3b7
[Ref 3]: raineorshine/npm-check-updates#420
[Ref 4]: raineorshine/npm-check-updates#423
@JoshuaKGoldberg
Copy link
Contributor

This is important because npm@3 requires gauge@2.6, which seems to be causing npm/npmlog#48 for me.

What a fun chain of dependencies!

@raineorshine
Copy link
Owner

Fixed in v3 branch via c0bd8b7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants