Ilia Kebets

the issue persists

They have both been deprecated: - https://sonarsource.github.io/rspec/#/rspec/S1537/javascript - https://sonarsource.github.io/rspec/#/rspec/S3723/javascript

in the latest ESLint recommended rules review, we decided to add this as a new rule, but didn't go through with it for some reason.

we could consider ignoring the issue if the condition is a single variable.

related to https://github.com/SonarSource/SonarJS/issues/2410

@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](https://github.com/SonarSource/SonarJS/pull/2986/commits/eb05832ee82627a41794aee09ddf85c1ff26a62f), we analyze legacy JS as well, so I see no point in...

> 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](https://sonarsource.github.io/rspec/#/rspec/S1527/javascript)'s test...

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...

we have added many rules from core eslint and some plugins, is this still a problem?

As mentioned here, we can close this: https://github.com/SonarSource/SonarJS/issues/2252#issuecomment-822409003