drop supporting Node.js 4

Node.js 4 became more legacy and outdated. It’s in maintenance mode since April 2017, which will end in April 2018.

It will give our codebase and us a breath of fresh air. There are a bunch of awesome stuff starting Node.js 6, which are missing in Node.js 4 :

• default function parameters
• rest parameters
• spread operator
• destructuring
• no need for 'use strict' to use let, const.
• …

since this will be a breaking change, when can we make this change?

[not-an-aardvark]

My opinion is that we should drop support for Node 7, and support ^6.14.0, ^8.11.0, and >=9.10.0 (currently the latest versions on each release line). There are a few reasons for this:

• The latest version of Node 6 has some features that are neither available on Node 7 nor on earlier versions of Node 6. It would be nice if we could use those features if we need them during the ESLint v5.x lifespan.
• Earlier versions of Node 6 (as well as 8, 9, and the latest version of Node 7) have known security vulnerabilities. As a result, I think most users will be using the latest version on their release line (e.g. 6.14.0), or they should be able to upgrade without too much difficulty. It seems unnecessary to prevent ourselves from using a set of features just to accommodate users who are using versions of Node with security vulnerabilities.
• Earlier versions of Node have known bugs which are fixed in later versions. If we officially supported outdated versions, then ostensibly we might need to work around a bug so that ESLint would work on versions of Node with that bug. This seems silly; a better solution would be for the user to upgrade their Node version so that the bug is fixed.
• Due to the way Travis works, we only run our tests on the latest version from each release line anyway. Even if we officially support Node 6.0.0, it will be difficult to make sure ESLint continues to work on that version without remembering when each Node feature was introduced.

I looked through Node’s changelogs and created a list of features that have been added to recent versions of the Node 6 release line. I omitted some features (e.g. relating to cryptography) which seem like they are unlikely to be used by ESLint in the future.

Features in Node 6.13.0 which are not in Node 7

• console.count()
• console.clear()
• Module.builtinModules
• process.ppid
• assert.fail() can take one or two arguments

Features in Node 6.13.0 which are not in Node 6.0.0

• (all of the features from the above list)
• NODE_NO_WARNINGS environment variable
• util.inspect supports %i and %f specifiers
• util.inspect.custom symbol
• ES6 iterator closing
• ES6 ArrayBuffers have correct prototype chains
• Symbol.species, Symbol.hasInstance, Symbol.match on strings
• Function .name property for object methods
• RegExp.prototype.flags
• Array iterators have the correct prototype chain
• Correct method behavior for subclassed arrays

---

I don’t think we have an immediate need for any of these features, but I can think of many plausible future scenarios where they would be nice to have.

[not-an-aardvark]

In today’s TSC meeting, the TSC decided that we will support Node ^6.14.0 || ^8.10.0 || >=9.10.0 in ESLint 5.0. (We decided to support Node 8.10 rather than starting support at Node 8.11 so that ESLint can be used on AWS Lambda.)