PR Checklist

• Addresses an existing open issue: fixes Bug: [no-shadow] Difference in handling from ESLint v10 no-shadow rule #12070
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

The no-shadow rule reports when a variable in an inner scope "shadows" (reuses the same name and hides) a variable in an outer scope. There is a deliberate exception when named function/class expressions are assigned directly to a variable of the same name that is allowed, common, and a harmless self-reference:

var a = function a() {};

In this case, the function's inner name only exists inside of the function itself, so reporting it as a shadow would be noisy and unhelpful.

The Bug

The isOnInitializer helper previously used a range-containment check to decide if this exception should be applied, by asking "is the inner variable located somewhere inside the declaration of the outer variable?" This definition was too loose because it suppressed shadow reports for named expressions anywhere inside an initializer, not just direct initializers, such as this case that should be reported because the inner definition is a genuinely separate binding that shadows the outer one:

const FooBarComponent = memo(function FooBarComponent() {});

ESLint v10 started to correctly report these cases.

The Fix

Instead of asking "is the inner name somewhere inside the initializer?", this PR rewrites to ask "is the inner expression literally the initializer?" It does this by:

1. Rewriting isOnInitializer to walk from the outer variable to its actual initializer node
2. Checking whether the inner function/class expression is that node through an identity check and not just range-containment

The unwrapExpression helper handles these still-valid cases where the function expression can transparently become a at runtime:

var a = foo || function a() {};
var a = foo ? function a() {} : bar;

The previous code also had a check for class expressions that verified the node type but not the definition type, even though a definition bundles both. The fix adds a missing DefinitionType.ClassName check for class expressions so that both innerDef.node.type and innerDef.type are now checked.

Fixes #12070.

💖