apicache not supported on Node 14 about apicache

[LukeXF]

Downgrading from 1.5.3 to 1.5.2 fixes this issue.

[kwhitley]

Fixed as of now @ 1.6.2

Thanks very much for everyone's patience!

[imnotjames]

Yeah - does look like in the 1.5.3 release that restriction was added but unclear the reasoning. It doesn't seem related to the redis fix included in the release?

[imnotjames]

#212 (comment) Looks like this is why?

So we continue to be plagued by issues trying to resolve tests using restify with Node v13+ (with or without gzip, I'm finding).

I'm proposing we finish updating the repo with the changes above (dropping old Node support), and temporarily drop official support for restify (specifically when used with node 13+). I'd add in a check to allow Travis to run the tests for restify+gzip with Node 12 and under. Either way, this will be part of the v2 release that will go into cruise control while we make a decent/all-new API for v3.

[kwhitley]

@imnotjames is correct... under Node 14, the restify and redis tests break down hard:

[kwhitley]

As I don't use restify or redis in my projects, I'd hoped someone else would spearhead the fixes there as I have no easy way to test these beyond the test suite.

In hindsight, and should apicache realistically get to a proper v2, it'll drop baked-in support for either, instead allowing any store mechanism with a standard interface to be plugged into apicache - making it backend agnostic. This would allow others to author/maintain the plugins, and apicache to simply focus on firing the appropriate cache calls and handling the response/headers side of things.

[kwhitley]

The next problem is that I have moved on past express in the last year and will likely focus on serverless (CloudFlare Workers) for the near future, and thus library focus will be on improved tooling in that workflow (Example: https://www.npmjs.com/package/itty-router). If someone would like to collaborate on a v2 of apicache, I'd be happy to discuss and pass the torch if the vision aligns! 👍