the rule `func-names` should behave differently depending on parser options
See original GitHub issueWhat you did?
ESLint config:
{
parserOptions: {
ecmaVersion: 5
},
rules: {
'func-names': [ 'error', 'as-needed' ]
}
}
The code:
var func = function /* no name here */ () {}
What you would like to happen?
With parserOptions.ecmaVersion
set to 5
or below, the option as-needed
for rule func-names
should behave the same as always
, since older versions of ECMAScript won’t automatically infer name
for anonymous functions. So as-needed
here means you always need to specify the name explicitly.
In other cases (parserOptions.ecmaVersion >= 6
), the behavior of option as-needed
should maintain status quo.
What actually happened?
ESLint was considering func
had an inferred name
and therefore complained nothing.
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Language parsing - how to deal with multiple options in a ...
So it's usually better to leave the grammar as it is and choose a different parsing algorithm, one which can explore more than...
Read more >Working with Rules - ESLint - Breword 文档集合
"problem" means the rule is identifying code that either will cause an error or may cause a confusing behavior. Developers should consider this...
Read more >Compiler Patterns
Here I just want to point out that this was a mistake, and caused the parser to act in very odd ways, looking...
Read more >Builtin - Neovim docs
This function can be used by plugins to implement options with validation and parsing logic. dictwatcherdel( {dict} , {pattern} , {callback} ) dictwatcherdel() ......
Read more >Subqueries
Depends on the input from a child query or queries to finish its execution. note. Subqueries are a really powerful way to filter...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Unfortunately that wouldn’t solve the problem. First, some parsers support experimental features, or they might only support some features of a particular ECMAScript version but not other features. In this particular case, there is a larger issue:
var foo = function(){}
is valid syntax regardless of whether the parser can parse ES5 or ES6. Function name inference happens at runtime, so whether it occurs will depend on the engine that’s executing the code, not the parser. It’s not possible for ESLint to determine what engine will be running the code, or whether that engine supports function name inference.You’re right. Thanks for your patience!