feat: Add ignoreOnInitialization option to no-shadow rule

[boutahlilsoufiane]

Prerequisites checklist

• I have read the contributing guidelines.
• The team has reached consensus on the changes proposed in this pull request. If not, I understand that the evaluation process will begin with this pull request and won't be merged until the team has reached consensus.

What is the purpose of this pull request? (put an "X" next to an item)

[X] Changes an existing rule

What changes did you make? (Give an overview)

Fix the issue here: #12687

Adding a new option ignoreOnInitialization to prevent reporting variables on initialization statements.
This is an example:

const person = people.find(person => person.name === "John");

Is there anything you'd like reviewers to focus on?

No.

[nzakas]

Functionally looks good. I just left some comments on how to clarify what is happening.

[boutahlilsoufiane]

Hi @nzakas, thank you so much for reviewing the PR.

[boutahlilsoufiane]

The requested changes are addressed.

[nzakas]

LGTM. Just want to give others the chance to review too. Thanks!

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Soufiane Boutahlil (9546417, bbf1dcc, d6f1a33)

[boutahlilsoufiane]

Hi @mdjermanovic, thank you for the explanation. The requested changes are addressed.

[ota-meshi]

I'm not the maintainer but I was interested in this fix so I looked at your code.
Is this fix intended to suppress reporting if it cannot be overridden (If misused, ReferenceError will occur) ?
If so, I think the following source code may need to be reported.
The following code will no longer be reported with this PR fix, but I don't think users will get a ReferenceError if they run it with const a = 42; removed.

const a = fn(()=>{
    class C {
        fn () {
            const a = 42
            return a
        }
    }
    return new C()
})

What do you think?

[boutahlilsoufiane]

@ota-meshi I think we should report the source code, I will update the pull request to include your example.

[nzakas]

@mdjermanovic can you check to see if your comments were addressed?

[mdjermanovic]

Comments regarding the behavior of this rule with hoist: "all" are addressed - it should report shadowing regardless of the positions of variable declarations.

My other concern is that it isn't clearly defined what we want to fix (only parameters of functions that are arguments of function calls that are variable initializers should be excluded from shadowing that variable?), and why it should be fixed.

The original example from #12687 is:

const person = people.find(person => person.name === "John");

This is shadowing, because at the moment when the inner person is created in an inner scope, the outer person already exists in the outer scope even though it may not be initialized yet. Furthermore, the outer person can be already initialized - we don't know whether the person => person.name === "John" function will be called right away or stored to be used later - so this shadowing doesn't have to be less potentially dangerous than shadowing a variable that is declared in a declaration that appears before this one. It should be only user's preference whether or not this example should be reported.

Problem is that the "hoist" option doesn't unambiguously specify how this example should be interpreted.

The hoist option has three settings:

• functions (by default) - reports shadowing before the outer functions are defined.
• all - reports all shadowing before the outer variables/functions are defined.
• never - never report shadowing before the outer variables/functions are defined.

Is this "shadowing before the outer variable is defined" or not? If we say that variable definition ends where the initializer ends, then it is "before", so hoist: "functions" or hoist: "never" should not report this example, and we have a false positive. On the other hand, it can be argued that the inner person identifier appears after the outer person identifier so it isn't "before", and therefore this rule works as intended (and this change might be undesirable for some users).

My opinion is that isn't clear if #12687 is a bug or intended behavior, and that we should resolve it by adding a new option rather than changing the current behavior.

[boutahlilsoufiane]

@mdjermanovic , You are right, the rule is working as expected, the inner variable person is shadowing the outer variable person, but developers are confused by this example:

const person = people.find(person => person.name === "John");

I think we should close the issue #12687 and this PR and add the ambiguous example in the documentation.

For the code source mentioned by @ota-meshi the rule doesn't report it, we need to create a new issue and I will fix it.

[mdjermanovic]

I'm not suggesting that we close #12687, but to consider adding an option for that behavior.

For the code source mentioned by @ota-meshi the rule doesn't report it, we need to create a new issue and I will fix it.

It works in the current version of this rule:

/* eslint no-shadow: error */

const a = fn(()=>{
    class C {
        fn () {
            const a = 42 // 'a' is already declared in the upper scope
            return a
        }
    }
    return new C()
})

Online Demo

[boutahlilsoufiane]

@mdjermanovic The requested changes are addressed.

[boutahlilsoufiane]

Hi @mdjermanovic, thank you so much for your time reviewing the PR. The requested changes are addressed.

[mdjermanovic]

@boutahlilsoufiane thanks for addressing all reviews! I think the most complex part of this change is now well done. I left some suggestions.

[boutahlilsoufiane]

Hi @mdjermanovic, thanks a lot for your contributions, you played a big role in this. The comments are addressed.

[boutahlilsoufiane]

Hi @mdjermanovic, thanks a lot for your time and your efforts, thanks a lot for taking the time to explain things more clearly, I think the option ignoreOnInitialization is stable due to your great notes.

[boutahlilsoufiane]

Hi @mdjermanovic, thanks a lot for your time and your efforts. The comment is addressed.

[mdjermanovic]

LGTM, thanks! I'll leave this open for a day in case someone else wants to review it before merging.

[nzakas]

Awesome work. Thanks for your patience and responsiveness.

[mdjermanovic]

@boutahlilsoufiane great work, thanks for contributing!

[boutahlilsoufiane]

Hi @nzakas and @mdjermanovic Thanks a lot for approving the changes. Thanks a lot, @mdjermanovic for your big help, this wasn't going to be merged without you.