the rule func-names should behave differently depending on parser options

[riophae]

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

[not-an-aardvark]

Thanks for the proposal.

I'm not sure it's a good idea to make rule behavior depend on the parser options -- we have done this a little bit in the past, and it has caused issues like #8744 (comment) for other parsers. If we do add this functionality, I think it would be better to make it a new rule option.

[riophae]

Thanks for your reply.

I have looked into that issue. As I understand it, the real problem is not about the idea of rules behaving differently when having a different ecmaVersion, but about ESLint should accept parser options supplied by third-party parsers (such as babel-eslint) and bring them into consideration when determining the behavior.

[not-an-aardvark]

To be more precise, parser options are options that can be provided by the user to configure the behavior of a parser. The ecmaVersion option happens to be used by espree (the default parser), but it's not necessarily used by any custom parser.

This means that a user could be writing ES6 code without the ecmaVersion: 6 option configured (if they are using a parser that parses ES6 by default), or they might be writing ES5 code even when the ecmaVersion: 6 option is configured (if they are using a parser that doesn't understand the ecmaVersion option). (They might also be writing code with ES6 syntax but with ES5 builtins and semantics, e.g. if they're transpiling their code with Babel).

In other words, the ecmaVersion parser option is not a reliable way for ESLint to determine whether the code in question uses ES6 semantics.

[riophae]

I see. Then what about asking custom parser to provide ESLint with in what ecmaVersion they are parsing the code and determine the behavior based on that instead of eslint.parserOptions.ecmaVersion?

[not-an-aardvark]

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.

[riophae]

You're right. Thanks for your patience!