New: Drop supports for Node.js 8.x and 11.x

[mysticatea]

This RFC is for ESLint 7.0.0 (probably we will start to publish alpha in December 2019 or January 2020).

Summary

This RFC drops supports for Node.js 8.x and 11.x because of end-of-life. (See nodejs/release to check the release schedule of Node.js)

Related Issues

• Allow use node version >8 eslint#10981 - Allow use node version >8
• Decide how to manage support for minor versions of Node eslint#11022 - Decide how to manage support for minor versions of Node

[mysticatea]

Hi.

• fs: remove experimental warning for fs.promises (Anna Henningsen) #26581
• stream:
  • implement Readable.from async iterator utility (Guy Bedford) #27660
  • make Symbol.asyncIterator support stable (Matteo Collina) #26989

https://nodejs.org/en/blog/release/v10.17.0/

Those may be useful for our asynchronous API #40. On the other hand, ^10.17.0 may be too new. What do you think?

[platinumazure]

It looks like 10.17.0 was only released on October 22, 2019, whereas 10.12.0 was released October 10, 2018 (more than 1 year before). This does feel like a significant difference.

I would probably lean towards "10.17.0 is too new", unless there are huge benefits to consuming that version in 7.0.0. You mentioned async ESLint, but how important are these changes to async ESLint? Is there another path forward that we could use with 10.12.0 (even if it's a little more painful to write)?

[btmills]

My impression in the past has been that we look at any features we might want to use in the latest release of each supported major version, and then support the lowest minor version in which those features exist. Since we at least won't release our next major until January when Node.js v8 is EOL, that gives people ~2.5 months minimum since 10.17 was released, which doesn't seem too quick.

[ljharb]

A few months is exceedingly quick for companies, for whom upgrading node is often a slow and expensive - and thus infrequent - process.

[mysticatea]

Thank you.

how important are these changes to async ESLint? Is there another path forward that we could use with 10.12.0 (even if it's a little more painful to write)?

Since streams got async iteration support, I thought that to use streams rather than just async iterators is more suitable for ESLint#executeOnFiles() and the formatter v2. If ESLint#executeOnFiles() returned a readable stream and the formatter v2 is a transform stream, then people can choose the favorite way from for-await-of and pipes to handle the lint results.

However, because Node provides interop APIs such as Readable.from() and maybe Transform.by(), this is not important.

---

I will keep this RFC as-is.