Should prefer-const flag an uninitialized `let x;` that is never assigned?

[jtbandes]

Environment

Playground

What parser are you using?

@typescript-eslint/parser

What did you do?

{
  "extends": [
    "eslint:all",
    "plugin:@typescript-eslint/all"
  ],
  "rules": {
  }
}

const foo = (two: string): void => {
  "use strict";
  
  // eslint-disable-next-line @typescript-eslint/init-declarations
  let one: string | undefined;

  if (one === two) {
    // Noop
  }
}

foo("");

What did you expect to happen?

In this code snippet, let one; is read but never assigned. I would expect some rule to flag it – the most appropriate one seems like it would be prefer-const.

What actually happened?

prefer-const does not complain about this code. (Maybe because const one; is not allowed syntax?)

Link to Minimal Reproducible Example

Playground

Participation

• I am willing to submit a pull request for this issue.

Additional comments

Here is a typescript-eslint version of the playground.

If prefer-const is not the right rule to flag this error, then what is?

[snitin315]

This is expected behavior for prefer-const, not a bug. prefer-const only applies when a variable is assigned a value but never reassigned. Since one is never assigned, ESLint can't suggest const (which requires an initializer).

In this case, enabling @typescript-eslint/init-declarations makes sense, as it ensures variables are initialized when declared. Since one is used, it isn’t flagged by no-unused-vars; otherwise, that rule would have caught it.

[snitin315]

I think enabling both init-declaration & prefer-const should solve it for your case?

[jtbandes]

Thanks for the reply – however I would personally disagree on some points:

Since one is never assigned, ESLint can't suggest const (which requires an initializer).

It's true that the rule would not be able to change let one; to const one; — however, it could change it to const one = undefined; which I believe would be a safe transformation, and it would fulfill the purpose of the rule (to avoid let when the variable is never reassigned).

enabling @typescript-eslint/init-declarations makes sense, as it ensures variables are initialized when declared

The way I understand init-declarations, it is purely stylistic: "This rule aims to bring consistency to variable initializations and declarations." – it's not really intended to prevent any "potentially buggy" code. If, stylistically, I am fine with this code:

let x;
if (...) {
  x = 1;
} else {
  x = 2;
}

Then I would want to keep init-declarations disabled. However, this now has the negative side effect that "buggy" code like the case I shared, where the variable is only read, is no longer flagged by any lint rule.

So I think it would be best to ensure that some rule flags this error even if init-declarations is disabled.

[kirkwaiblinger]

In addition to @jtbandes thoughts, I would just add that initialized vs uninitialized let has intentionally slightly different behavior in the type system in TS, so it's not really recommended to use init-declarations in TS. Most of the time this would all be moot because TS would issue a use-before-assign error, but it allows uninitialized variables whose type includes undefined.

TL;DR unfortunately "enable init-declarations" isn't a satisfying resolution in this context.

[kirkwaiblinger]

One more thought, sorry. A let that is read (which even lets it evade no-unused-vars as well!) but never initialized is basically for sure a programmer error. Since it is guaranteed to have value undefined, it's basically just a crappy alias for undefined that's subject to TDZ.

Understandable if this specific pattern ought to be flagged by a dedicated/separate rule, rather than prefer-const, but it seems like prefer-const suggesting const x = undefined would be an intuitive and equally cromulent way to clue a developer in to their mistake. At the end of the day, either resolution would be fine. It's just that init-declarations is overbearing for this concern because it also flags lets that are eventually initialized, not just ones that are never initialized.

[snitin315]

Hmm, I agree that we should have a way to flag this case. I'd like to hear the team's thoughts on this. Do you think we should consider it? If yes:

• Should it be added to prefer-const, or would it be better as a separate rule?

// @eslint/eslint-tsc