Proposal: removing parserOptions.experimentalObjectRestSpread option

[mysticatea]

Context

Since ESLint 4.18.0, we have supported Rest/Spread Properties in formal with parserOptions.ecmaVersion: 2018. So the parserOptions.experimentalObjectRestSpread option has finished its role.

The parserOptions.experimentalObjectRestSpread option has some confusion because we added it early time.

• There are three node types for the same syntax; ExperimentalRestProperty, RestProperty, and RestElement. And spread properties are so. This is unfortunate for plugin ecosystem.

Also, the parserOptions.experimentalObjectRestSpread option sometimes has hidden bug fixes in acorn. For example:

• Fix: Fix parsing of async keyword-named object methods (#352) espree#353
• Fix: async shorthand properties (fixes #340) espree#341

The cause is that we make some overridden methods on espree to implement it. In fact, the implementation of parserOptions.experimentalObjectRestSpread has a bug about the duplication check of ES modules currently.

export const b = 1
export const {a, ...b} = obj // "SyntaxError: Identifier 'b' has already been declared" in `ecmaVersion:2018`, but not in `experimentalObjectRestSpread:true`.

Proposal

Remove the parserOptions.experimentalObjectRestSpread option in the next major version, 5.0.0.
To replace it by parserOptions.ecmaVersion: 2018 to migrate.

This is similar to Migrating to 2.0.0 we have done in past.

Pros

• Reducing confusion about AST node types. This removal removes ExperimentalRestProperty and ExperimentalSpreadProperty.
• Reducing bugs. This removal removes the double management of the implementation of Rest/Spread Properties. This will prevent bugs such as Fix: async shorthand properties (fixes #340) espree#341 and Fix: Fix parsing of async keyword-named object methods (#352) espree#353. We can get bug fixes in acorn quickly in the future.
• Making consistent. We specify ECMA262 Standard version by parserOptions.ecmaVersion option since 2.0.0. The parserOptions.experimentalObjectRestSpread option is the last exception.

Cons

• Many users are using the parserOptions.experimentalObjectRestSpread option. This removal can cause confusion in migrating to 5.0.0.

[platinumazure]

My thoughts (off the cuff): It's hard to say how many people are relying on this, so I wonder if we should consider deferring this for 5.0 and implementing in 6.0, to allow more time for rule/plugin authors to make the transition.

[not-an-aardvark]

In today's TSC meeting, the TSC decided to do the following:

• Remove the experimentalObjectRestSpread option from espree in a breaking change.
• Update eslint@5 to convert experimentalObjectRestSpread: true to ecmaVersion: 2018 and print a warning message.
• Plan to remove this behavior in eslint@6.

[ljharb]

Could it be kept, but only for ecmaVersions 2015-2017?

[not-an-aardvark]

My impression is that the team is generally not in favor of keeping the option, for a few reasons:

• The option adds significant complexity to espree.
• The option was experimental and was never intended to be a long-term feature.
• In general, we don't have individual flags for syntax features.
• The option adds significant complexity for rule authors, because there are several different AST representations for object rest/spread emitted by different parsers. Changing to the ecmaVersion: 2018 behavior would simplify the situation.

For further discussion, see #9986 (comment).

[ljharb]

My concern is that there may be codebases that wish to keep object rest/spread but do not wish to enable async/await, or async iterators, or **.

[not-an-aardvark]

The recommendation for those codebases would be to enable ecmaVersion: 2018 and use something like no-restricted-syntax to forbid syntax that they don't want to allow. (Alternatively, they could use a different parser, but that would probably be harder.) We generally don't support toggling syntax features independently in the parser -- experimentalObjectRestSpread was a temporary exception.

[btmills]

As suggested by @not-an-aardvark:

As a separate change later on, we can probably remove all of the rule code that tests for ExperimentalRestProperty etc.

[mysticatea]

FWIW, I have published a plugin to disallow each syntactic feature individually: https://www.npmjs.com/package/eslint-plugin-es

[mysticatea]

I'll work on this.

[satazor]

I share the same concerns as @ljharb.

Lets consider a project that was written with Node.js >= 8.6 in mind. According to node.green, only the object spread and object rest spread features from es2018 are implemented. Therefore, it would be safer to declare ecmaVersion: 2017 and enable experimentalObjectRestSpread in said projects. If didn't do so, using for await of would not cause any linting errors, but would fail when running the code.

This was just an example. There are a lot of other projects that are locked to ecmaVersion < 2018 but use object rest/spread because they either use Node.js >= 8.6 or use Babel.

Please consider keeping experimentalObjectRestSpread for ecmaVersion < 2018.

[mysticatea]

@satazor Please consider to use node/no-unsupported-features rule in eslint-plugin-node