After upgrading lru-cache to ^8.0.0 node >= 16.14 is required

[jimenezmaximiliano]

Version 3.2.1 is now incompatible with node < 16.14 because lru-cache (https://github.com/isaacs/node-lru-cache/blob/42fc1a3ac57604a1d26ead49ce87f4b3518505e1/package.json) requires node >= 16.14.

[vlasky]

Yes I also need node-mysql2 to maintain Node.js 14 compatibility for a little while longer. I'm using it with Meteor, which still depends on Node.js 14 to support fibers.

The next major release of Meteor 3.0 will no longer need fibers support, so will be compatible with Node.js 16 and above. It is expected to be released within the next few months.

[sidorares]

From my side no practical reason for lru-cache migration other than trying to have more incremental (and thus potentially safer) updates with dependencies

I'm happy to revert back to a latest version of lru-cache that still supports node 14 unless updates fix known serious bugs / vulnerabilities

[jimenezmaximiliano]

That sounds sensible to me.
Version 7 seems to be supported but there's no documentation about how long that will be the case. I personally don't see a reason to upgrade it as of today. And if it's upgraded, this library's node engine requirements should be updated too I guess (it would need a new major version probably).

[sidorares]

This is commit bumping required node version: isaacs/node-lru-cache@b3b6d24

The reason is signal.reason support, previously it would warn / suggest polyfill - isaacs/node-lru-cache@ca76768

looks like v7.18.3 is the latest version we can use with node 14

[jimenezmaximiliano]

Should I create a PR for this? I'm not sure how impactful the change in signal.reason is

[WikiRik]

I think making a PR to set lru-cache back to v7 is good, there does not seem to be any security issues patched by using v8.

[wellwelwel]

I think making a PR to set lru-cache back to v7 is good, there does not seem to be any security issues patched by using v8.

Hi, @WikiRik!

Two opposing thoughts

1) By using a legacy environment, the user understands that some packages may not be supported in their most modern versions
2) The package must support even legacy versions

Seeing the Sequelize #16058 PR merged by you, I see that you already deal with this facts

---

Some points to consider

• The Node 14.x had its end of life on 2023-04-30
• fix: LRU constructor #2004 (comment)
• Until the date of this comment, the lru-cache is at version 10.0.0
• So, what are the benefits of the most recent versions of lru-cache?

---

A simple suggestion

Indicate the node engine compatibility at package.json:

node-mysql2/package.json

Lines 53 to 55 in 4d0f0de

	"engines": {
	"node": ">= 8.0"
	},

---

Reverting lru-cache to 7.x

As in #1953 (comment):

According to lru-cache changelog, between versions 7.18.0 and 10.0.0, no critical performance or security updates were made.

Then, just check again to make sure there are no conflicts with NextJS and Nuxt:

• fix: LRU constructor #2004 (comment)
• TypeError: LRU is not a constructor #1885

[sidorares]

from 9.0 changelog:

Bring back minimal polyfill.

I wonder if 9/10 is compatible again with node 14 because of that. If yes I'd prefer upgrading to the latest version

[sidorares]

package.json engine check can be overridden by the user if that's the only problem

[WikiRik]

Thanks for your input @wellwelwel @sidorares
I agree that lru-cache should be upgraded and that it's possible now that Node 14 is EOL. But I believe that that should be done in a major release, and that for mysql2 v3 this change should be reverted. lru-cache v9 brings back a minimal polyfill which does not seem to work for Node 8 (ignoring the engine check obviously), which is the lowest Node version mysql2 v3 should support.

[sidorares]

@WikiRik I agree it should have been a major version bump, that was my mistake
But given that we already here, reverse ( if happens ) is probably a major version bump as well