Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Decide which Node versions ESLint 6 should support #11456
This issue is a follow-up from today's TSC meeting. The TSC decided that ESLint 6 will drop support for Node 6, with the precise Node version support TBD.
Based on #11022, it seemed like the consensus was that we should pick Node version requirements based on specific features we might want to use in ESLint, rather than just picking the latest Node versions as we did for v5.x. (However, not a lot of team members have chimed in on #11022 -- feel free to add to that discussion, particularly if you disagree with that general approach.) I've mostly gone with that approach, although I've also taken into consideration which Node versions users will typically be upgrading to.
We currently support everything above Node 8.10.0 on the Node 8 release line. I don't think we should tighten that requirement, since AWS Lambda only supports Node 8.10.0. We've received a few requests to loosen that requirement with ESLint 5, but I'd rather not do that either since it could be nice to have features like
I think we should drop support for Node 9, since it's been at EOL for almost a year.
We currently support all versions of Node 10. There aren't any features we specifically need in Node 10 aside from the ones that in Node 8, so I'd recommend starting at the first Node 10 LTS release (i.e.
Node 11 is going to be EOL in June, so I don't think too many users will be stuck on old versions of it. As a result, I'd arbitrarily suggest picking the latest version as of now, i.e. 11.10.1.
So I think our Node version support for ESLint 6 should be:
Well, every Node release line includes bugfixes, so in that sense we're in the same situation now as we were with 8.x. It wasn't originally supposed to be a special exception.
I think it would be nice to make our Node requirement specific by excluding infrequently-used versions, since it reduces the likelihood of inadvertently introducing bugs on supported versions. (With our current Travis setup, we only test the latest Node release on each release line anyway, so if a bug were introduced that only affects 10.0.0, we probably wouldn't notice. We've discussed adding builds explicitly for versions like 10.0.0 in the past, but there were concerns about builds taking too long.)
However, I don't feel strongly about it and would be fine with something like