You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When components in nested scopes use the same snippet names, ESLint's no-shadow rule detects that the inner scope is shadowing the snippet name from the outer scope.
While the example shows a contrived use-case, I ran into this pretty quickly once I started creating reusable UI components. I've temporarily disabled ESLint's no-shadow rule, but of course that isn't ideal.
Agreed, it's not a bug in ESLint. What's not ideal is that it's quite common for components to accept parameters with the same names, and for them to be nested, so this makes the use of snippets as parameters break in what is likely a common case.
Oh I see. So snippet tags define variables, but users don't intend variable definitions, and no-shadow rule doesn't seem to work well when slot names are intended.
I think we need to create a rule that extends no-shadow rule, and the new rule will exclude snippet tags used only with slot names from reporting.
Describe the bug
When components in nested scopes use the same snippet names, ESLint's no-shadow rule detects that the inner scope is shadowing the snippet name from the outer scope.
While the example shows a contrived use-case, I ran into this pretty quickly once I started creating reusable UI components. I've temporarily disabled ESLint's no-shadow rule, but of course that isn't ideal.
Reproduction
Example with ESLint configuration on GitHub
Example with the same code on REPL
Logs
System Info
Severity
annoyance
The text was updated successfully, but these errors were encountered: