Update: ecmaVersion defaults to 5, and allows "latest"

[aladdin-add]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ x] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

• set ecmaVersion defaults to 5, make it not depend on espree's defaults
• allow ecmaVersion => "latest"

Is there anything you'd like reviewers to focus on?

all these changes should not affect 3rd-party parsers.

[nzakas]

We also need to update the docs to mention that “latest” is allowed.

[nzakas]

LGTM

[nzakas]

There seems to be some confusion about how ecmaVersion currently works and it seems like some folks are assuming everyone understands already. Can someone outline the various scenarios, including when parser is and isn’t present, and what the result is currently? I think that will help provide the missing context to this PR.

[aladdin-add]

well, I will try. the current ecmaVersion normalization is simple:

• undefined => undefined
• 2015 => 6

That's say, eslint depends on the parser's defaults option. In the PR, it changed the normalization to:

• undefined => 5
• latest => espree.latestEcmaVersion
• 2015 => 6

it will be a breaking change, when all the following conditions are met:

• not set ecmaVersion
• using a 3rd-party parser, but it's default ecmaVersion is not 5.

[ljharb]

@aladdin-add and also, when that parser actually pays attention to the ecmaVersion?

[mdjermanovic]

ESLint currently doesn't automatically set parserOptions.ecmaVersion if parserOptions.ecmaVersion wasn't specified in user's configuration.

Espree's default is ecmaVersion: 5. Other parsers have different defaults.

Espree is about to change its default ecmaVersion, but we don't want that change to affect ESLint users.

Ideally, ESLint should automatically set parserOptions.ecmaVersion to 5 if parserOptions.ecmaVersion wasn't specified in user's configuration, whenever ESLint is used with Espree but not with another parser (as it would be a breaking change if that parser had a different default).

The problem is: it seems difficult for Linter to know that the parser is Espree when user specifies parser: "espree", because in that case @eslint/eslintrc loads parser and sends the parser object and absolute path to Linter.

[nzakas]

Thanks everyone, so I think what we want is this:

ecmaVersion	parser	result
undefined	undefined	parser: espree, ecmaVersion: 5
undefined	"espree"	parser: espree, ecmaVersion: 5
undefined	"other-parser"	parser: "other-parser", ecmaVersion: undefined
2022	undefined	parser: "espree", ecmaVersion: 2022
2022	"espree"	parser: "espree", ecmaVersion: 2022
2022	"other-parser"	parser: "other-parser", ecmaVersion: 2022

The problem is: it seems difficult for Linter to know that the parser is Espree when user specifies parser: "espree", because in that case @eslint/eslintrc loads parser and sends the parser object and absolute path to Linter.

Can we compare that object to require("espree") to determine this? Or compare the absolute path to require.resolve("espree")?

[aladdin-add]

Can we compare that object to require("espree") to determine this? Or compare the absolute path to require.resolve("espree")?

I just thought a very edge case: someone might want to use a different version of espree.
parser: "./node_modules/espree"

node_modules
├── espree
└── eslint
    └── node_modules
        └── espree

But I think it's fine to not normalize it - espree was used as a 3rd-party parser in this case.

will update as @nzakas suggested (if no objections).

[mdjermanovic]

Can we compare that object to require("espree") to determine this? Or compare the absolute path to require.resolve("espree")?

Sounds good to me!

I just thought a very edge case: someone might want to use a different version of espree.
parser: "./node_modules/espree"

node_modules
├── espree
└── eslint
    └── node_modules
        └── espree

But I think it's fine to not normalize it - espree was used as a 3rd-party parser in this case.

I agree. If someone explicitly installs another version of espree, then it's like they're using a third-party parser with its own defaults.

Though this might also happen unintentionally when another dependency has espree as a dependency, and the other version of espree ends up in the top node_modules. But that setup seems already broken. Looks like it generally isn't a good idea to explicitly set "parser": "espree" in eslint config unless the user really wants a different version, because "parser": "espree" doesn't guarantee that the espree version specified in eslint's package.json will be used.

[nzakas]

I had a realization: Linter is not supposed to use Node.js-specific functionality because it is also used in the browser, so I don't think using require() make much sense.

So, at this point, I think the path of least resistance is to leave the Espree default ecmaVersion as 5. We can still support "latest" in ESLint but don't have to worry about the additional complexity we're running into now. With flat config, we will have an opportunity to choose a different default ecmaVersion for ESLint and it will be much easier to special-case Espree because Linter will have a direct reference to it.

Thoughts>

[aladdin-add]

I had a realization: Linter is not supposed to use Node.js-specific functionality because it is also used in the browser, so I don't think using require() make much sense.

do you mean using require.resolve()? But in the PR, I didn't use it, I just used parser === espree to check it, so it seems not an issue.

[nzakas]

Ah ok. LGTM. 👍

[mdjermanovic]

LGTM, thanks!

[nzakas]

I just realized that this can be included before v8, do we want to merge now?

[mdjermanovic]

I just realized that this can be included before v8, do we want to merge now?

Yes, I also think this doesn't depend on eslint/espree@b068cea. We can merge this for an ESLint v7 minor version.

[aladdin-add]

yes, and eslint/espree@b068cea depends on this one(set ecmaVersion defaults to 5) :)