Parsing error: Unexpected token => when using eslint --init on post-ES2015 files

[jhpratt]

Tell us about your environment

• ESLint Version: 4.12.1
• Node Version: 9.5.0
• npm Version: 5.6.0

What parser (default, Babel-ESLint, etc.) are you using? Default

Please show your full configuration: N/A

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

(async () => {
});

eslint --init

Followed by answering prompts as follows:

• File? fileName.js
• Format? YAML
• ES6 features? Yes
• ES6 modules? Yes
• Environment? Node
• JSX? No

What did you expect to happen?

.eslint.yaml generated

What actually happened? Please include the actual, raw output from ESLint.

(~/tmp/example.js:1:11) Parsing error: Unexpected token =>
Error: (~tmp/example.js:1:11) Parsing error: Unexpected token =>
    at getSourceCodeOfFile (/usr/local/lib/node_modules/eslint/lib/util/source-code-util.js:38:15)
    at filenames.forEach.filename (/usr/local/lib/node_modules/eslint/lib/util/source-code-util.js:94:28)
    at Array.forEach (<anonymous>)
    at getSourceCodeOfFiles (/usr/local/lib/node_modules/eslint/lib/util/source-code-util.js:93:15)
    at configureRules (/usr/local/lib/node_modules/eslint/lib/config/config-initializer.js:165:23)
    at processAnswers (/usr/local/lib/node_modules/eslint/lib/config/config-initializer.js:288:18)
    at inquirer.prompt.then.secondAnswers (/usr/local/lib/node_modules/eslint/lib/config/config-initializer.js:536:32)
    at <anonymous>
Determining Config: 0% [------------------------------] 0.0s elapsed, eta 0.0s

[not-an-aardvark]

This is happening because we only ask whether the user is using ES6, and we don't supply an option for later ES versions. When the question was added, ES2015 was the latest version.

Maybe we should add a list of ES versions to choose from, rather than just asking about ES6.

[jhpratt]

Ah, that certainly makes sense. I know tons of people refer to ES6 as "modern" JS, even though it most certainly isn't. Enumeration of options would certainly resolve the issue.

[platinumazure]

TSC Summary: When running eslint --init and asking it to inspect source code of files, we ask if users are using ES2015/ES6 features but not if they might be using later ES versions (to allow, e.g., exponentiation or async/await syntax). This causes a parsing error, since we aren't parsing the files with a recent enough ecmaVersion.

Probably the best way to resolve this is to change the "Using ES6 features" question in eslint --init to a version selection (ES2015, ES2016, etc. until latest available).

TSC Question: Should we change the "Using ES6 features" question to an ecmaVersion selection question?

[alberto]

Actually, I was planning to submit a PR to accomplish this. One issue I found is we only have env "es6". So I dug into the issue of the actual "es6" behaviour and the possibility of having different version for parser options and globals. I'm willing to champion this, but we would need to decide on how to proceed.

[not-an-aardvark]

There was a discussion about that at #9109. There is a potential issue that if someone uses both env: es6 and env: es6, they might merge and end up with parserOptions: {ecmaVersion: 2015}, which could be confusing. But after thinking about it more I'm not sure this should be a blocker for adding env: es8 (or env:es2017).

I do wonder whether envs should be deprecated in favor of extendable (possibly built-in) configurations since the two are sort of redundant, but that's a bigger discussion that doesn't need to happen right now.

[alberto]

Yes, I was refering to that conversation (among others).

There is a potential issue that if someone uses both env: es6 and env: es6
I think you made a typo here. ;)

One thing we have to decide is what would be the behavior of env for the different es*. Will they also set up parserOptions or just globals?

There was also the problem with the precedence arised in #8291

If we deprecated env I assume it would be a soft deprecation, right? Otherwise it would create a lot of hassle.

If we want to move away from the es6 behavior regarding parserOptions, another possible option would be to add es2015, es2016, ... make these only set globals, and "deprecate" es6. It's not ideal and it would have to be well documented but I think it would do the trick

[platinumazure]

What about this approach?

1. Ask for ecmaVersion (this replaces the question about using ES6)
2. If ecmaVersion >= 6, add new question to ask if ES6 globals should be allowed
3. If ecmaVersion >= 6 (e.g., 8 for purpose of examples) and ES6 globals should be allowed, then set { env: { es6: true }, parserOptions: { ecmaVersion: 8 } } (or whatever ecmaVersion). Else if ecmaVersion >= 6, set { parserOptions: { ecmaVersion: 8 } } only.

This is kicking the can down the road in terms of globals in later ES versions, but it would allow us to fix the original reported issue.

[fatcerberus]

@platinumazure What do you mean by "ES6 globals"?

[platinumazure]

@fatcerberus I'm referring to globals like Set, Map, etc. that are defined with ES6.

We intentionally allow users to set ecmaVersion to 6 or greater, while simultaneously not allowing the ES6 globals. It's a pretty rare use case but I've heard of users occasionally wanting to allow the new syntax but not use the new types, or vice versa. Most users would presumably want the ES6 globals and the new syntax.

[alberto]

ES2017 added Atomics and SharedArrayBuffer already.

[platinumazure]

@alberto Do we have an env configured for those globals yet? I think that might be a separate issue.

[not-an-aardvark]

In today's TSC meeting, the TSC accepted this issue.