Clarify the status of S1527 ('future-reserved-words')

[yassin-kammoun-sonarsource]

We noticed when upgrading ESLint to 8.10.0 that S1527 is no longer able to raise issues on some of the keywords it mentions in its description (eb05832).

We are now facing parsing errors depending on which reserved keywords we try to use as identifiers. That's actually the case when analyzing the code snippets of S1527's test suite with SonarQube 9.3.

We therefore need to clarify the status of the rule.

[yassin-kammoun-sonarsource]

See https://cirrus-ci.com/task/5680462529036288?logs=analyze#L84

[ilia-kebets-sonarsource]

@vilchik-elena The list does not seem to have any new "future reserved keywords": https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#future_reserved_words

As you mentioned here, we analyze legacy JS as well, so I see no point in removing adopted keywords. The current list contains either adopted keywords or reserved ones, with no dropped keywords. I don't see any issue with the current rule implementation. The list of words is in sync with the RSPEC.

• I think we should add new reserved keywords if they come by.
• If a reserved keyword gets adopted, the JS runner will throw an error if one attempts to use it, so keeping it in the rule is not an issue.
• If a reserved keyword gets dropped like "Future reserved words in older standards", we can keep it in the rule as well because of legacy codebases. We can rethink our position on them if many people start reporting FPs.

[ilia-kebets-sonarsource]

We are now facing parsing errors depending on which reserved keywords we try to use as identifiers. That's actually the case when analyzing the code snippets of S1527's test suite with SonarQube 9.3.

Indeed, when running the test cases from S1527 in SonarJS, SQ 9.7 fails to parse the file:

[ilia-kebets-sonarsource]

The parsers that we use do not have an option to parse legacy reserved keywords:

• @babel/eslint-parser: https://babeljs.io/docs/en/babel-parser#options
• @typescript-eslint/parser: https://typescript-eslint.io/architecture/parser/

We have managed to parse tests with legacy reserved keywords because ESLint uses the Espree parser by default which has the allowReserved option.

[yassin-kammoun-sonarsource]

Solved while updating the rule metadata.