Open blewisio opened 6 years ago
hi @blewisio, I think I'd be open to this change. Would it be possible to do it in a non-breaking way? Does node 6 support promises where node 4 didn't?
Generally speaking, I think trading compatibility for cleaner syntax is a bad deal unless it can really simplify the library. I thinkkk promises would be enough of a reason though 😊
Hey @matthewmueller - thanks for the quick response and interest!
As a library maintainer, the risk of not upgrading your ES/node version is that your code will diverge from the rest of the ecosystem - the syntax becomes so different that it's like writing in a different language. I don't think too many people are using v0.10 or v0.12 of node these days anyway, so it's almost a self-imposed limitation! Additionally, end-of-life generally means that that major version will stop receiving security updates.
That being said, I'm happy to target v4 instead of v6 if you'd like to be more conservative with compatibility (v4 and v6 both have similar support for promises, by the way)
@blewisio how significant would the changes be (as in how much es6 would you foresee)? (Meanwhile, there's no need to bump to node version until we need to.)
So... the testing dependencies mean that our tests all fail on older versions (per travis ci).
I think updating to the most recent LTS version, we’d be in good shape.
(In terms of bumping to Node 6. Updating to ES6 or later may be more of an issue.)
So ... @blewisio ... we're now targeting LTS (V6) and above. You've likely lost interest in this, but if you're still interested I think we'd be open to it...
I'd like to update the code to be ES6+ and beyond to make
x-ray
more modern. In tandem with that, it'd be great to update the engine inpackage.json
to require Node v6.0 or above since v4.0 was recently deprecated.