-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
fix(eslint-plugin): [no-shadow] ignore ordering of type declarations #10593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,7 +11,7 @@ | |
{ | ||
allow?: string[]; | ||
builtinGlobals?: boolean; | ||
hoist?: 'all' | 'functions' | 'never'; | ||
hoist?: 'all' | 'functions' | 'functions-and-types' | 'never' | 'types'; | ||
ignoreFunctionTypeParameterNameValueShadow?: boolean; | ||
ignoreOnInitialization?: boolean; | ||
ignoreTypeValueShadow?: boolean; | ||
|
@@ -28,6 +28,13 @@ | |
AST_NODE_TYPES.TSConstructorType, | ||
]); | ||
|
||
const functionsHoistedNodes = new Set([AST_NODE_TYPES.FunctionDeclaration]); | ||
|
||
const typesHoistedNodes = new Set([ | ||
AST_NODE_TYPES.TSInterfaceDeclaration, | ||
AST_NODE_TYPES.TSTypeAliasDeclaration, | ||
]); | ||
|
||
export default createRule<Options, MessageIds>({ | ||
name: 'no-shadow', | ||
meta: { | ||
|
@@ -63,7 +70,7 @@ | |
type: 'string', | ||
description: | ||
'Whether to report shadowing before outer functions or variables are defined.', | ||
enum: ['all', 'functions', 'never'], | ||
enum: ['all', 'functions', 'functions-and-types', 'never', 'types'], | ||
}, | ||
ignoreFunctionTypeParameterNameValueShadow: { | ||
type: 'boolean', | ||
|
@@ -88,7 +95,7 @@ | |
{ | ||
allow: [], | ||
builtinGlobals: false, | ||
hoist: 'functions', | ||
hoist: 'functions-and-types', | ||
ignoreFunctionTypeParameterNameValueShadow: true, | ||
ignoreOnInitialization: false, | ||
ignoreTypeValueShadow: true, | ||
|
@@ -513,15 +520,30 @@ | |
const inner = getNameRange(variable); | ||
const outer = getNameRange(scopeVar); | ||
|
||
return !!( | ||
inner && | ||
outer && | ||
inner[1] < outer[0] && | ||
// Excepts FunctionDeclaration if is {"hoist":"function"}. | ||
(options.hoist !== 'functions' || | ||
!outerDef || | ||
outerDef.node.type !== AST_NODE_TYPES.FunctionDeclaration) | ||
); | ||
if (!inner || !outer || inner[1] >= outer[0]) { | ||
return false; | ||
} | ||
|
||
if (!outerDef) { | ||
return true; | ||
} | ||
Comment on lines
+527
to
+529
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I went over this again and made one small change. I think I've introduced an unnecessary change to the original implementation (returning I don't think this code is reachable (all tests seem to pass regardless of this change), and I couldn't reproduce this in a test. Still, just to be sure, I've changed this to match the original implementation. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Now that it's on its own This part of the code seems to originate from the original eslint rule and is there from the very beginning. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I'd just ignore Codecov here. Its reporter isn't perfect. |
||
|
||
if (options.hoist === 'functions') { | ||
return !functionsHoistedNodes.has(outerDef.node.type); | ||
} | ||
|
||
if (options.hoist === 'types') { | ||
return !typesHoistedNodes.has(outerDef.node.type); | ||
} | ||
|
||
if (options.hoist === 'functions-and-types') { | ||
return ( | ||
!functionsHoistedNodes.has(outerDef.node.type) && | ||
!typesHoistedNodes.has(outerDef.node.type) | ||
); | ||
} | ||
|
||
return true; | ||
} | ||
|
||
/** | ||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'm thinking this exposes a general learning: don't use
enum
option types for "when do I X?" questions. Eventually folks will want to do something that could be better expressed as an object. I.e. here:...but, to your point, I think it would be even more disruptive to extend the base rule option to a wholly different format in that way. For now I think the
enum
is fine. If this rule gets even more complicated over time then we can always switch to the object later.tl;dr: agreed as-is 👍