Temporal Dead Zone variable usage, new-rule/rule-change
See original GitHub issueI 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:
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.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:7 (4 by maintainers)
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.
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.