The rule was written before optional chaining, and this "use before assigned" case was never added.

It's very, very rare for people to write "use before assigned" variables, and even rarer that people use optional chaining with them.

this has to be fixed in typescript, uninitialized variables should be reported by typechecker as X | undefined not X or we should be able to receive information that variable is uninitialized in some way

https://www.typescriptlang.org/play?ssl=8&ssc=1&pln=1&pc=1#code/DYUwLgBGIM5gXBOAnAlgOwOYG4BQuAzAV3QGMxUB7dCADwgAoBKCAb1wk4mXCORuhwAdKCxgAFngC++WszxA

let test: string;
function x () {
    return test.length;
}
x();

this code is going to compile without error but, its actually going to produce runtime error

We can use scope analysis to handle this. Simply put we can find the declaration, and if it's a variable with no intiailiser - then we can ignore the check.

We already have similar code in the no-unnecessary-type-assertion lint rule:

Relevant TS issue: microsoft/TypeScript#20221

that's good idea to use scopes for that

there is only one issue with external variables, eg. exported from another file, but that should be even rarer case

Across module boundaries there be Dragons.
So I'm more than happy for us to fail the case!

Note from #9206 that var is also a relevant case:

if (Math.random()) {
  var x = 1;
}
if (x) {}

I think the rule's behavior is correct in this case. And I think that let x: T; should not be treated as T | undefined for the purposes of this rule, because it is not treated that way by TS.

IMO if you plan to read a variable in its uninitialized state, you should use let x: T | undefined; (or, more verbosely, let x: T | undefined = undefined;). If your intention is that it will always be set before being read (whether or not this is provable from static analysis, e.g. due to setting the variable in a closure), let x: T is appropriate.

Note also that the code which is proposed to be allowed in this issue is dangerous code that hides a type error from TS. TS assumes that foo is not undefined. If it were possibly undefined, foo?.length would have type string | undefined, which is an error to compare to a number with the < operator. (playground)

let foo: string | undefined;

const setFoo = (): void => {
  if (foo?.length < 1) {
//    ~~~~~~~~~~~~~~~ TS ERROR 18048: 'foo.length' is possibly 'undefined'. 4:7 - 4:18     
    foo = 'foo';
  }
};

Furthermore, if we remove the optional chain, it's not a type error (playground)

let foo: string;

const setFoo = (): void => {
  if (foo.length < 1) {
    foo = 'foo';
  }
};

Which cannot be the case for removing an unnecessary optional chain on an accurately typed variable.

This is all to say, let foo: string; means "by the time you read foo it will be a string", and TS makes correctness assumptions about that with much broader implications than just the behavior in this rule. Therefore, regardless of how one feels about that decision on TS's part, I think it would be wrong to retcon it to mean anything else for this rule. Use let foo: string | undefined;.

Note from #9206 that var is also a relevant case:

if (Math.random()) {
  var x = 1;
}
if (x) {}

Fortunately, that's a TS use-before-define error 🙂, so I think we can avoid the mental strain of thinking about var, unless we can think of another case where it specifically matters.

I think the rule's behavior is correct in this case. And I think that let x: T; should not be treated as T | undefined for the purposes of this rule, because it is not treated that way by TS.

Since I wrote this, it was pointed out to me by @bradzacher that this rule autofixes this case, which can cause unsafe behavior. That's a very good point!

I still believe strongly that the report is correct, but I agree that it's problematic to autofix this case. I believe the appropriate resolution would be to detect this case and downgrade the autofix to a suggestion.

I'd like to open this issue to PRs for that resolution if there are no objections?

filed #9565 to propose flagging the code in the issue report for failing to initialize foo