node-mysql2
node-mysql2 copied to clipboard
After upgrading lru-cache to ^8.0.0 node >= 16.14 is required
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.
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.
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
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).
This is commit bumping required node version: https://github.com/isaacs/node-lru-cache/commit/b3b6d245e1754f509fd8c40f162e447291de70d7
The reason is signal.reason support, previously it would warn / suggest polyfill - https://github.com/isaacs/node-lru-cache/commit/ca767681450f0b179145481a6cea1f1eb4c5fe6f
looks like v7.18.3 is the latest version we can use with node 14
Should I create a PR for this? I'm not sure how impactful the change in signal.reason is
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.
I think making a PR to set
lru-cacheback 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.xhad its end of life on 2023-04-30 - https://github.com/sidorares/node-mysql2/pull/2004#issuecomment-1544789420
- 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:
https://github.com/sidorares/node-mysql2/blob/4d0f0de6066606837393479e9ec0d5019231875a/package.json#L53-L55
Reverting lru-cache to 7.x
As in https://github.com/sidorares/node-mysql2/issues/1953#issuecomment-1510697365:
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:
- https://github.com/sidorares/node-mysql2/pull/2004#issuecomment-1544407218
- #1885
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
package.json engine check can be overridden by the user if that's the only problem
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.
@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