no-inner-declarations inconsistency

Tell us about your environment

• ESLint Version: 6.3.0
• Node Version: 10.16.0
• npm Version: 6.9.0

What parser (default, Babel-ESLint, etc.) are you using?

default

Please show your full configuration:

Configuration

module.exports = {
  parserOptions: {
    ecmaVersion: 2015,
  }
};

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

Demo link

/*eslint no-inner-declarations: ["error", "both"]*/

if (foo)
  var a;

if (foo)
  function f(){}

function bar() {
  if (foo)
    var a;

  if (foo)
    function f(){}
}

eslint index.js

What did you expect to happen?

To be consistent, either 4 errors or no errors?

This rule requires that function declarations and, optionally, variable declarations be in the root of a program or the body of a function.

Are these declarations in the root/body? Also, the documentation is later more specific:

“functions” (default) disallows function declarations in nested blocks

“both” disallows function and var declarations in nested blocks

What actually happened? Please include the actual, raw output from ESLint.

2 errors:

11:5  error  Move variable declaration to function body root  no-inner-declarations
14:5  error  Move function declaration to function body root  no-inner-declarations

/*eslint no-inner-declarations: ["error", "both"]*/

if (foo)
  var a; // no error

if (foo)
  function f(){} // no error

function bar() {
  if (foo)
    var a; // error

  if (foo)
    function f(){} // error
}

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

Yes, if this is confirmed to be a bug.

Perhaps the rule should allow only these places for function and var declaration nodes:

• Program > node
• ExportNamedDeclaration > node
• ExportDefaultDeclaration > node (function only)
• Function > BlockStatement > node

meaning that there should be 4 errors in the above example, but I’m not sure is this the intention of this rule.

[platinumazure]

I would be 👍 for having 4 errors in your example.

[mdjermanovic]

@anikethsaha Sure, thanks!

It isn’t entirely clear what should be done, but it looks like a good idea to continue the discussion on a PR.