no-inner-declarations inconsistency
See original GitHub issueTell 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.
/*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.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:14 (12 by maintainers)
I would be 👍 for having 4 errors in your example.
@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.