Decide which Node versions ESLint 6 should support

[not-an-aardvark]

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 Module.builtinModules and correct require.resolve behavior with the paths argument, both of which were introduced in Node 8.10.0.

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. ^10.13.0) since this is probably where most users start using Node 10.

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:

^8.10.0 || ^10.13.0 || >=11.10.1

[ilyavolodin]

I think 8.10 was the exception out of the rule because of the introduction of new features that were fixing broken behavior. For other versions, I don't see the point of being too specific. I would be fine with anything greater then 10 or 11.

[not-an-aardvark]

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 ^8.10.0 || >=10.0.0 if other people are opposed to making the requirements so specific.

[ilyavolodin]

I mean Node 8.10 was a special case, because our code wasn't working with versions <8.10. While something like that might happen again, it's unlikely, since those fixes were more like breaking changes.

[not-an-aardvark]

Are you sure? From what I recall, our code was working fine with Node <8.10, but we chose to only support things above that version in case we wanted to use that version's features in the future.

[ilyavolodin]

Hmm... You might be right. I'm a bit hazy on the details of that conversation.

[nzakas]

I'm 👍 to ^8.10.0 || ^10.13.0 || >=11.10.1

[not-an-aardvark]

TSC Summary: This issue proposes setting our Node version support in ESLint 6 to ^8.10.0 || ^10.13.0 || >=11.10.1.

TSC Question: Should we accept this proposal?