fix(cache): Switch to lru-cache to save ourselves from unlimited memory consumption

[iarna]

No description provided.

[coveralls]

Coverage increased (+0.03%) to 95.238% when pulling 4ebabd3 on lru-cache into ab35a90 on latest.

[ljharb]

@isaacs heads up that this was a breaking change for node < 4 in a non-major version. There's no "engines" declaration and you didn't stop testing on node 4 until after this was landed.

I'm using yargs 7 → read-pkg-up 1.0.1 → read-pkg 1.1.0 → normalize-package-data 2.5.0 → hosted-git-info 2.8. I'm not using a lockfile because it's in a package, not an app, and it'd be really appreciated if 2.8+ could be reverted, and republished as v3. (another alternative would perhaps be to use an older version of lru-cache that didn’t use node 4+ syntax)

[isaacs]

Sure, I can do that.

But seriously. @ljharb. You gotta have a frank talk with whoever you're supporting who uses node < 4. It's not safe. They're putting their systems at risk. Whatever the cost to upgrade, it surely is less than the cost of getting pwned, and if they're doing new builds with new OSS code, this problem will only get worse.

[ljharb]

Thanks, appreciate it.

[ljharb]

@isaacs hmm, it looks like the use of const here (added in a5a91ac) is causing the same issue. Could that be converted to var for a v2.8.4 release?

[isaacs]

@ljharb Done.

Have you had a sit-down with whoever is running your code on node 0.x yet? It's irresponsible to let them continue doing this.

[ljharb]

Thanks!

It’s not necessarily irresponsible. There are many uses of node, and many tech stacks, that make the insecurities of old versions irrelevant. (Additionally, although not for this package, old node is a great standin for old browsers, so on anything that could run in browsers, it’s very useful to maintain support)