PR Checklist

• Addresses an existing open issue: fixes #000
• That issue was marked asaccepting prs
• Steps inContributing were taken

Overview

Theno-unnecessary-type-assertion rule has custom logic for handling literal types:

To my understanding, the current logic is as follows: If the cast type is a literal type, it would only be reported if it's the initializer of aconst declaration. If it isn't a literal type, it would be reported as long as the assertion isn'tas const (along with the asserted type and expression having the same type).

Zooming into the logic of handling literals, I think the rule tries to predict when a literal would be widened. To my understanding (quotingWidening and Narrowing in Typescript), a literal would be widened in the following cases:

• Literal widening only happens to literal types that originate from expressions. These are called fresh literal types.
• Literal widening happens whenever a fresh literal type reaches a "mutable" location.

To my understanding, the rule somewhat handles (2) as it only reports literals that are assigned to aconst variable declaration but ignores (1). (2) is still somewhat ignored, as "fresh" literals are relevant here too.

In my opinion, this logic may be improved so the rule can catch additional cases that it currently misses (and not fail on some false positives), mostly around "fresh literals".

I'm basing this on theTypeScript Handbook,Widening and Narrowing in Typescript andthe literal widening PR, along with testing this on the playground. See this comment#1056 (comment), as I think they're somewhat related.

This isn't something I have a thorough understanding of, but it seems like the case with the following simplified example:

declareconsta:'foo';// `b` has the non-widened type of 'foo'letb=a;// `c` has the widened type of `string`letc='foo';

Seethis playground link for bugs in the current implementation which I think may be improved.

The goal of sending this draft POC PR is to make it easier to discuss or test this on the deploy preview playground. This PR roughly implements what's described above (along with fixing#10257 and#10257 (comment)).

This is a POC proposal to a topic I'm far from being an expert in, so I'd be happy for opinions on this.

Note: Should some of these assumptions be checked/verified by the TypeScript devs? There might be edge cases that I missed that require APIs that aren't currently public.

Please let me know if this should be an issue instead; I wasn't sure if this should be an issue, a draft PR, or an issue accompanied by a draft PR.

Without taking "fresh literals" into consideration, I think differentiating between these two would be difficult:1,2.