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

npm warning with move-file #1237

Open
3 tasks done
Zamiell opened this issue Dec 6, 2022 · 9 comments
Open
3 tasks done

npm warning with move-file #1237

Zamiell opened this issue Dec 6, 2022 · 9 comments
Milestone

Comments

@Zamiell
Copy link
Contributor

Zamiell commented Dec 6, 2022

  • I have searched for similar issues
  • I am using the latest version of npm-check-updates
  • I am using node >= 14.14

Steps to Reproduce

Install the npm-check-updates package with yarn.

You should get this warning:

warning npm-check-updates > pacote > @npmcli/run-script > node-gyp > make-fetch-happen > cacache > @npmcli/move-file@2.0.1: This functionality has been moved to @npmcli/fs
@raineorshine
Copy link
Owner

The @npmcli/move-file dependency was removed from cacache about one month ago and was released in v17.0.2. It just hasn't bubbled up the hierarchy yet:

npm-check-updates@16.5.0
└─┬ pacote@15.0.6
  ├─┬ @npmcli/run-script@6.0.0
  │ └─┬ node-gyp@9.3.0
  │   └─┬ make-fetch-happen@10.2.1
  │     └─┬ cacache@16.1.3
  │       └── @npmcli/move-file@2.0.1 deduped
  └─┬ cacache@17.0.0
    └── @npmcli/move-file@2.0.1

The latest cacache was added to make-fetch-happen in v11.0.1, but node-gyp is still using make-fetch-happen v10.x. This is currently being tracked in nodejs/node-gyp#2756. I recommend 👍'ing and subscribing to that issue, since that's the current blocker.

I would do an override but the cacache upgrade is a major version change, so I don't really want to risk it for a non-critical warning.

@raineorshine raineorshine added this to the v17 milestone Jun 25, 2023
@That-Guy977
Copy link

This should be resolved now that the upstream blocker has been merged and released, there's no other blockers in the dependancy tree.

npm-check-updates@16.10.16
└─┬ pacote@15.2.0
  ├── cacache@17.1.3
  └─┬ npm-registry-fetch@14.0.5
    └─┬ make-fetch-happen@11.1.1
      └── cacache@17.1.3 deduped

@raineorshine
Copy link
Owner

@That-Guy977 Thanks for the heads up.

Updated and published in v16.10.17.

@That-Guy977
Copy link

This seems to have reappeared as an issue from a different dependency, but it seems pretty weird

npm-check-updates@16.14.6
└─┬ pacote@15.2.0 (15.2.0)
  └─┬ @npmcli/run-script@6.0.2 (^6.0.0)
    └─┬ node-gyp@9.4.1 (^9.0.0)
      └─┬ make-fetch-happen@10.2.1 (^13.0.0!?)
        └─┬ cacache@16.1.3
          └── @npmcli/move-file@2.0.1

@raineorshine
Copy link
Owner

raineorshine commented Nov 3, 2023

@That-Guy977 It looks like node-gyp@9.4.1 reverted back to make-fetch-happen@10.0.3.

https://github.com/nodejs/node-gyp/blob/v9.4.1/package.json
https://github.com/nodejs/node-gyp/blob/v9.4.0/package.json

In this commit: legobeat/node-gyp@dd50c2c

This reverts commit legobeat/node-gyp@02480f6, thereby
rolling back dependency make-fetch-happen from ^11.0.3 to ^10.0.3.

The upgrade is breaking for node-fetch users as it has transitive
dependencies with syntax incompatible with supported Node.js versions.

@That-Guy977
Copy link

Guess I checked the wrong package.json 😓

Should this issue be reopened then?

@raineorshine raineorshine reopened this Nov 3, 2023
@raineorshine
Copy link
Owner

raineorshine commented Nov 3, 2023

node-gyp@10 doesn't have this problem, so the solution is for us to upgrade pacote which will pull in the latest node-gyp. This will be a breaking change since it requires bumping the node engine.

This needs to be coordinated with upgrading the rest of the dependencies that bump the node engine. I have started work in the v17 branch, but haven't had time to continue working on it. If someone would like to continue the process of bumping dependencies and fixing the few regressions that occur, then we could get that released.

@Zamiell
Copy link
Contributor Author

Zamiell commented Nov 3, 2023

I decided to try helping, but after forking and cloning my fork, I was greeted with this:

james@1qaz MINGW64 /d/Repositories/npm-check-updates (v17)
$ npm ci

> npm-check-updates@17.0.0-0 prepare
> husky install && bash test/bun-setup.sh

husky - Git hooks installed
npm ERR! code EBADPLATFORM
npm ERR! notsup Unsupported platform for bun@1.0.8: wanted {"os":"darwin,linux","arch":"arm64,x64"} (current: {"os":"win32","arch":"x64"})
npm ERR! notsup Valid OS:    darwin,linux
npm ERR! notsup Valid Arch:  arm64,x64
npm ERR! notsup Actual OS:   win32
npm ERR! notsup Actual Arch: x64

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\james\AppData\Local\npm-cache\_logs\2023-11-03T13_47_40_401Z-debug-0.log

AFAIK Bun isn't supported on Windows. I understand that Bun is fast, but by using it in this project, you are shutting out all the Windows users in the world who want to collaborate with you and help, and Windows is the most popular operating system in the world.

@raineorshine
Copy link
Owner

Hi @Zamiell. I absolutely I agree. Can you open a new issue for this? I'd be happy to respond there.

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

3 participants