The newest version of glob and rimraf now is not supported for node 14

[wghule]

The newest version of glob and rimraf now is not supported for node 14。if necessary，can you make major version upgrade?

[isaacs]

If you are using an EOL node version as old as node 14, you must pin your dependencies. Your package manager should already be filtering out versions with a mismatched engines requirement, doesn't that work?

[Mr0grog]

Your package manager should already be filtering out versions with a mismatched engines requirement, doesn't that work?

NPM, at least, will log a nice warning but proceed with installation of the incompatible version and give you a successful exit code. Nothing in most build pipelines, for example, is going to stop or flag a failure here, which could certainly cause people some surprising problems! This also poses a problem for libraries that depend on glob, since it implicitly raises their Node.js minimum requirements without any changes on their part (in fact, I’m glad I just happened to be scrutinizing this update — for other, abnormal reasons — since this is exactly the position I was about to be in).

I certainly thought this was pretty surprising in a patch release and I’d generally agree with @wghule that this is a breaking change for some people. At the very least, it deserves a callout in the changelog.

[isaacs]

npm should prioritize an engine match over a version that has an engine conflict. It only warns if it has to choose a version with an engines conflict, or throws if --engines-strict is set.

[isaacs]

https://github.com/npm/npm-pick-manifest/blob/1841ad297f2c22b8a76ede7de680dc639635a824/lib/index.js#L177

[Mr0grog]

Well, I can only say that I tried it and, in practice, it installed an incompatible version. (On Node.js 16, required "glob": "^10.0.0", resulted in 10.4.3 installed.)

[Mr0grog]

Maybe the code you’re pointing to is different in versions of NPM that are compatible with Node.js 16? I don’t know all the details of NPM’s own complex tree of dependencies across versions and, FWIW, I don’t feel like it is worth digging to understand what might be going wrong on a version of NPM for a version of Node.js that is probably no longer supported.

I think the bigger issue is just that, in practice, at least one dependency manager (and probably others?) don’t automatically solve this issue for users the way you are expecting it to.

[kerm1it]

I think it is correct to change the baseline version of nodejs, but the best practice is to release a major version to do this, because many other npm packages rely on your dependencies and use the semantic version specification. Now you have upgraded the baseline version of node through the patch version, which has caused problems for many upstream dependencies. Because many of our projects still rely on node 16 and are not ready to upgrade to version 18, I think this change is a break change.

So see if you can release a new patch to restore the baseline version support of node, and then change the baseline of node version by upgrading the major version, so that we can upgrade to node 18 when we are ready.

[chetankpr007]

I am getting this as well error [email protected]: The engine "node" is incompatible with this module. Expected version ">=18". Got "16.20.1"
I am not using glob directly but dependency on some other module. Can this be resolved?

[wghule]

And please make the older version of glob、jackspeak、lru-cache、rimraf and so on still work，not deprecated，thanks。It afffect many npm package and project。

[zkk2019]

This problem can be configured to set the package version

[SBKila]

did someone try to override version via package
"overrides": {...}

[zamalatb]

If you are using an EOL node version as old as node 14, you must pin your dependencies. Your package manager should already be filtering out versions with a mismatched engines requirement, doesn't that work?

you also broke node 16 support! Make major version for this dude

[kerm1it]

If we directly depend on these packages, it seems that we can solve it by locking the version, but there is such a situation:

packageA depends on glob, and the version number is ^10.0.0, packageB depends on packageA, if I only use package B in the project, then I can't directly lock the version of glob.

In addition, some people may say that you can use yarn.lock or yarn resolutions to lock the version, but when npm i -g a-cli or yarn global add a-cli, these methods don't work, and only the latest version that meets the conditions will be resolved and installed according to the semantic version.

[Lms24]

We're also running into this issue with Node 16 at the moment. Please revert 8a69def and drop Node 16 support (if necessary) in a major release. Thank you!

[SBKila]

hi, I have temporary fix for my usecase comming from [email protected] using yarn install
Using npm no issue.

in package.json I add :
"resolutions": {
"archiver/archiver-utils/glob": "10.4.2",
"glob/jackspeak": "3.4.0",
"glob/path-scurry/lru-cache": "10.3.0"
}

[Lms24]

Yeah, this does not only affect glob but also jackspeack and lru-cache. I opened issues in the respective repositories.

[isaacs]

https://nodejs.org/en/blog/announcements/nodejs16-eol/

It's been EOL for 10 months. Pin your deps and only upgrade carefully if you are using EOL platform versions.