ES3 reserved words

[zloirock]

The issue: zloirock/core-js#980

In the code used char as a variable name. The ESLint config contains ecmaVersion: 3, till this week here was used the default ESLint parser. char is a ES3 reserved word:

ESLint parsed it without any errors or warnings. However, this code might not work in some ES3 engines.

[nzakas]

Please update your issue to use our bug report template and we will take a look. Thanks.

[zloirock]

@nzakas all this info you were able to find in core-js repo by the link above.

ESLint Version: 7.32.0 https://github.com/zloirock/core-js/blob/4a56ece64adc9653a4c8a648955a5a95aba22fd8/package.json#L37
Node Version: 16 https://github.com/zloirock/core-js/blob/4a56ece64adc9653a4c8a648955a5a95aba22fd8/.github/workflows/lint.yml#L12
npm Version: 7.21.0 https://github.com/zloirock/core-js/blob/4a56ece64adc9653a4c8a648955a5a95aba22fd8/package.json#L55
Operating System: ubuntu-latest https://github.com/zloirock/core-js/blob/4a56ece64adc9653a4c8a648955a5a95aba22fd8/.github/workflows/lint.yml#L11

Default ESLint parser with ecmaVersion: 3 option https://github.com/zloirock/core-js/blob/4a56ece64adc9653a4c8a648955a5a95aba22fd8/.eslintrc.js#L989-L991

Full configuration https://github.com/zloirock/core-js/blob/4a56ece64adc9653a4c8a648955a5a95aba22fd8/.eslintrc.js

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

https://github.com/zloirock/core-js/tree/4a56ece64adc9653a4c8a648955a5a95aba22fd8/packages/core-js

npm i && npm run lint

What did you expect to happen?

I expect a parsing error on
https://github.com/zloirock/core-js/blob/4a56ece64adc9653a4c8a648955a5a95aba22fd8/packages/core-js/modules/web.url.js#L121
https://github.com/zloirock/core-js/blob/4a56ece64adc9653a4c8a648955a5a95aba22fd8/packages/core-js/modules/es.symbol.description.js#L34
since it should be a syntax error in ES3

What actually happened? Please copy-paste the actual, raw output from ESLint.

eslint --ext .js,.mjs,.json ./

Steps to reproduce this issue:

1. Copy https://github.com/zloirock/core-js/tree/4a56ece64adc9653a4c8a648955a5a95aba22fd8
2. Run npm i && npm run lint

Are you willing to submit a pull request to fix this bug? No.

---

I don't think that it made understanding the issue simpler, I just spent time filling out a useless bureaucratic form.

[aladdin-add]

I was able to repro, and it seems an issue in acorn.

[mdjermanovic]

Acorn has an option to modify this behavior:

https://github.com/acornjs/acorn/tree/master/acorn#interface

• allowReserved: If false, using a reserved word will generate
  an error. Defaults to true for ecmaVersion 3, false for higher
  versions. When given the value "never", reserved words and
  keywords can also not be used as property names (as in Internet
  Explorer's old parser).

Consequently, espree (ESLint's default parser, which uses acorn) allows reserved words when ecmaVersion: 3 is specified, since we are not setting this option so the defaults apply.

I'm not sure what was the reasoning for these defaults in acorn. With allowReserved: false, it does throw a parsing error (astexplorer.net snippet).

We could consider setting allowReserved: false here, but that feels like a breaking change. Thoughts?

[zloirock]

As an option, instead of parsing error, it can be a new rule that will forbid the usage of ES3 reserved words as variables names.

[mdjermanovic]

As an option, instead of parsing error, it can be a new rule that will forbid the usage of ES3 reserved words as variables names.

This could be also achieved with the existing no-restricted-syntax rule:

/* eslint no-restricted-syntax: [
    "error",
    {
        selector: "Identifier[name=/^(?:abstract|boolean|byte|char)$/]",
        message: "ES3 reserved word"
    }
]*/

var char; // error

Online Demo

This configuration disallows the list of reserved words - I added only the first 4 for the example - everywhere where estree spec uses Identifier nodes (variables, labels, property names in object literals/member access, etc.).

Would this work for you?

[mdjermanovic]

id-denylist also provides similar functionality, though with some exceptions (e.g., property names are allowed).

[zloirock]

@mdjermanovic I know, but I don't think that it's fine to recommend adding the ES3 reserved words list to those rules for all who need ES3 support.

[aladdin-add]

the easiest way is to use the allowReserved option:

"parser": "espree",
"parserOptions": { "ecmaVersion": 3, "allowReserved": false}

I also agreed this can be the default.

---

oops, sorry it would not be working, as espree do not pass unknown options to acorn: https://github.com/eslint/espree/blob/63bd0bc46adfbcd3a71d4cc222aa3923b76ebcf2/lib/espree.js#L69

[mdjermanovic]

As an option, instead of parsing error, it can be a new rule that will forbid the usage of ES3 reserved words as variables names.

@mdjermanovic I know, but I don't think that it's fine to recommend adding the ES3 reserved words list to those rules for all who need ES3 support.

I agree this isn't an ideal solution, but it's a currently available workaround. We don't have core rules to check syntax, that rule seems more like a candidate for eslint-plugin-es.

"parser": "espree",
"parserOptions": { "ecmaVersion": 3, "allowReserved": false}

This would solve the problem in a non-breaking way, but we aim to avoid exposing Acorn options for various reasons.

I think that espree should just always pass "allowReserved": false to acorn, but that would have to wait for espree/eslint v9.

[zloirock]

eslint-plugin-es

This plugin seems dead. Anyway, this issue looks like an ESLint core problem.

that would have to wait for espree/eslint v9

Why not add it to v8 while it's still in beta?

[aladdin-add]

filed the issue in acorn: acornjs/acorn#1062 to see if they want to change the default.

[mdjermanovic]

Why not add it to v8 while it's still in beta?

espree v8.0.0 has been already released, and the changes in eslint v8.0.0 are already announced.

[nzakas]

Because there’s agreement that this is a bug, I’m marking as accepted. We just need to determine how to proceed.

I’m guessing we don’t have a lot of ES3 usage right now, and ES3 code using reserved words will throw a runtime error, so even though this is a breaking change, I think the impact to end users would be minimal. So, we may want to evaluate this a bit differently than other breaking changes.

[mdjermanovic]

We could fix this in Espree as a breaking change, release Espree v9.0.0, and then use Espree 9 in ESLint v8.0.0.

[ljharb]

All of my packages are authored in ES3, and none of them use char as a variable name, so I'd love to see this fix come in, even as a patch.

[mdjermanovic]

Should we actually set allowReserved: "never" for ES3, to also disallow obj.char and var obj = { char: 1 }?

By https://www-archive.mozilla.org/js/language/E262-3.pdf (if that's the right document?):

Identifier ::
     IdentifierName but not ReservedWord

MemberExpression :
     ...
     MemberExpression . Identifier

ObjectLiteral :
     { }
     { PropertyNameAndValueList }
PropertyNameAndValueList :
     PropertyName : AssignmentExpression
     PropertyNameAndValueList , PropertyName : AssignmentExpression
PropertyName :
     Identifier
     StringLiteral
     NumericLiteral

[nzakas]

We could fix this in Espree as a breaking change, release Espree v9.0.0, and then use Espree 9 in ESLint v8.0.0.

That’s what I was thinking, too.

Should we actually set allowReserved: "never" for ES3, to also disallow obj.char and var obj = { char: 1 }?

Yes. Reserved words were completely illegal in ES3.

[nzakas]

Note from marijn about Acorn's default:

Most browsers in the ES3 era allowed reserved words to be used in scripts, hence this default. It is not going to change for backwards-compatibility reasons.

[nzakas]

Opened a PR: eslint/espree#513

[mdjermanovic]

In yesterday's TSC meeting, we decided to accept this change for ESLint v8.0.0.

The change will be made directly in Espree. We'll release Espree v9.0.0 and use Espree v9 in ESLint v8.0.0.

Reserved words will also be disallowed in property names, such as obj.char or var obj = { char: 1 }. The new behavior is spec-compliant, and it isn't configurable.

This change only affects ESLint users with the default parser and "parserOptions": { "ecmaVersion": 3 }.

[ljharb]

Turns out there's ES3 browsers where these reserved words work fine - native and int, in particular, work fine in IE 6, for example.