Temporal Dead Zone variable usage, new-rule/rule-change

I was a little surprised to find that usage of a variable within its temporal dead zone (henceforth “TDZ”) is not considered to be an error in the eslint:recommended ruleset.

Example of TDZ:

{            // <-- block scope, not function scope
    foo;     // <--+
             //    |-- TDZ for `foo`
             // <--+
    let foo; // <-- ReferenceError: foo is not defined
}

Looking back in the archives I see a couple of relevant closed Issues:

• #10375: concluded that no-use-before-define is sufficient
• #9677: timed out

I think this space would benefit from either a new rule, or some adjustment. The rest of this post outlines the existing situation and possible solutions. Feedback welcomed!

---

Existing rule, no-use-before-define

This rule is not enabled by the ruleset eslint:recommended.

The rule can catch TDZ usage, see this ESLint demo.

However, it also catches similar var usage, at which point we have ventured into subjective territory.

It is possible that people wish to use var hoisting in this manner. It is very unlikely that people want to use TDZ ReferenceError as part of control flow.

Proposal(s)

(1) New Rule, e.g. no-temporal-dead-zone-usage

A new rule could be created, and I hope included in the eslint:recommended ruleset to benefit the masses.

It would notify users of situations where a let/const variable is referenced before its declaration.

(2) Extend existing no-use-before-define

Parameters could be added to the existing rule to support this use case. I haven’t fleshed out what these might look like, possibly an additional property. Would have to consider how folks might enable the TDZ checking without also enabling var hoisting errors.

I would hope that the TDZ checking could be made part of eslint:recommended via this avenue too, though this may be trickier.

Comparison

With respect to the Core Rule Guidelines, both approaches are:

• Widely applicable ✔️
• Generic ✔️
• Atomic ✔️
• Library agnostic ✔️

An additional rule might fall foul of Uniqueness and “No conflicts”.

Issue Template

What category of rule is this?

[X] Warns about a potential error (problem) [ ] Suggests an alternate way of doing something (suggestion) [ ] Enforces code style (layout) [ ] Other (please specify:)

Why should this rule be included in ESLint (instead of a plugin)?

This rule would warn about JavaScript language use and would ideally be included in the eslint:recommended ruleset. It would detect usage that is almost universally a bug.

Are you willing to submit a pull request to implement this rule?

Yes

Does this change cause the rule to produce more or fewer warnings?

Depends on configuration. It would cause fewer warnings for someone wishing to block TDZ usage but wanting to use var hoisting.

[mysticatea]

Thank you for this proposal.

I think that no-undef rule is the best rule to report the clear TDZ accesses.

However, we cannot report all TDZ errors in the static analysis because TDZ is a timing matter rather than a structural matter.

{
    foo(); // TDZ ReferenceError: `x` is not defined.
    [0].forEach(foo); // TDZ ReferenceError: `x` is not defined.
    setTimeout(foo, 0); // OK!
    let x = 0;
    foo(); // OK!

    function foo() { x } //← access `x`
}

[eslint-deprecated[bot]]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.