Bug: [@typescript-eslint/no-unnecessary-type-assertion] False positives for "as const" assertions

[ashvinsrivatsa]

Before You File a Bug Report Please Confirm You Have Done The Following...

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have searched for related issues and found none that matched my issue.
• I have read the FAQ and my problem is not listed.

Playground Link

https://typescript-eslint.io/play/#ts=5.4.2&fileType=.tsx&code=KYDwDg9gTgLgBAYwgOwM7wLYEMoGthRwC8cARNngaXFqoiugNwCwAUKJLHAJbIwEAzLAmBwAIlhhY4AbzZw4FfFABccGAE8wwCAMU5lLVgoBuWADYBXYGvRReAcyMBfNgMvIEMbikRRgksASUgAUAJRqwdJyxvRo8ABGtKIkMvqUqunKcM5GCv4wllDIsnAAdBVJqMAANHBmVjZk1LlszkA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6Jge1tiacTJTIAhtEK0ipWkOTJE0fJQ5N0UOdA7RI4MAF8QOoA&tsconfig=N4KAvkA&tokens=false

Repro Code

export const marker = "marker" as const;
export interface Data {
  marker: typeof marker;
  value: string;
}
function createData(): Data {
  const base = { marker: marker };
  return { ...base, value: "" };
}

ESLint Config

module.exports = {
  "rules": {
    "@typescript-eslint/no-unnecessary-type-assertion": "error"
  }
}

tsconfig

{
}

Expected Result

The first line of this code should not report an error for the as const assertion, since this assertion is necessary - removing it is a TypeScript compilation error (see TypeScript playground).

Actual Result

Starting in typescript-eslint@7.3 (presumably #8558), the first line of this code reports a @typescript-eslint/no-unnecessary-type-assertion error.

Additional Info

No response

[bradzacher]

This seems like a bug in TS.
Without the as const the type of marker is "marker". With it the type is the same.

This is evidenced by the fact that TS types your interface as requiring the property marker: "marker", not marker: string.

The fact that TS widens the object type to have marker: string unless the variable declaration is specifically marked with as const seems like counter-intuitive and incorrect behaviour.

It's probably worth filing an issue upstream.

[JulienBara-360]

Hi @bradzacher,
I met the same problem today.
If it helps, rolling back from v7.4.0 to v6.21.0 removed the false positive.
In the meantime, I kept typescript on v5.4.3.

[LukeNotable]

The fact that TS widens the object type to have marker: string unless the variable declaration is specifically marked with as const seems like counter-intuitive and incorrect behaviour.

It's probably worth filing an issue upstream.

Maybe, but as it stands the rule is doing more harm than good by wrongly flagging such as const as safely removable.

[kgregory]

Ran into this as well.

It appears to have been introduced with 7.3.0, possibly with #8558 - Does not occur after rolling back to 7.2.0.

[kirkwaiblinger]

Hmmmm, note also that

-export const marker = "marker" as const;
+export const marker = "marker";
export interface Data {
  marker: typeof marker;
  value: string;
}
function createData(): Data {
- const base = { marker: marker };
+ const base = { marker: marker } as const;
  return { ...base, value: "" };
}

works... and makes a whole lot more sense anyway. It seems really odd that using as const in the first line would have an effect on the type of base granted marker has the same type whether or not as const is explicitly used.

[kgregory]

works... and makes a whole lot more sense anyway.

In this case, yes, but that will affect all other attributes of the object. For example, if base were of a type with an array attribute, applying as const to base would type that array as readonly. (see this playground)

[kirkwaiblinger]

-export const marker = "marker" as const;
+export const marker = "marker";
export interface Data {
  marker: typeof marker;
  value: string;
}
function createData(): Data {
- const base = { marker: marker };
+ const base: { marker: typeof marker } = { marker: marker };
  return { ...base, value: "" };
}

works also.

As does

-export const marker = "marker" as const;
+export const marker = "marker";
export interface Data {
  marker: typeof marker;
  value: string;
}
function createData(): Data {
- const base = { marker: marker };
+ const base = { marker: marker as typeof marker };
  return { ...base, value: "" };
}

and, of course

-export const marker = "marker" as const;
+export const marker = "marker";
export interface Data {
  marker: typeof marker;
  value: string;
}
function createData(): Data {
 const base = { marker: marker };
- return { ...base, value: "" };
+ return { marker, value: "" };
}

So it has something to do specifically with the widening behavior when creating a mutable object whose type is inferred. More I think about it, it really just seems surprising to me personally that the example in the issue report works in the first place.

[kirkwaiblinger]

works... and makes a whole lot more sense anyway.

In this case, yes, but that will affect all other attributes of the object. For example, if base were of a type with an array attribute, applying as const to base would type that array as readonly. (see this playground)

@kgregory yeah, that's a fair point. and that irked me too. See #8721 (comment) for 3 more examples that don't though 🤣

[kirkwaiblinger]

I also note that putting const marker = 'marker' as 'marker' also has the same impact in these examples as const marker = 'marker' as const.

I guess it seems like we're running into a case where a type assertion has broader effect than setting the type of the thing being asserted on.

• Maybe that's a bug in TS (as @bradzacher suggested in Bug: [@typescript-eslint/no-unnecessary-type-assertion] False positives for "as const" assertions #8721 (comment))
  • We should probably get clarity on that first before considering action on our side
• Maybe that's a intentional behavior in TS.
  • If so, maybe it's possible to distinguish between the "necessary" and "unnecessary" cases
  • More likely, it's not possible/feasible to do so, and we'd need to choose between erring on the side of permitting unnecessary as const assertions or having this sort of false positive edge case (wouldn't be the only one either, see Bug: [no-unnecessary-type-assertion] false positive when casting to HTMLElement (from Element) #9007).

Curious what other team members think

[kirkwaiblinger]

I've just learned that TS appears to have intentional behavior around the "freshness" of a const variable type (see microsoft/TypeScript#52473 (comment)), though it's not clear that it's a particularly external-facing concept. Would have to do some more research.

In any case, I think it explains what we're seeing here, though I'm not sure that it is obvious what we should actually do about it.

@bradzacher, thoughts?

[JoshuaKGoldberg]

@kirkwaiblinger I agree with you that we should get clarity on whether this is a TypeScript bug. +1 that it seems odd how having the as const on line 1 doesn't change the reported type of the const marker, but does change the type of the const base = { marker: marker }.

Marking as blocked on someone filing an issue on TypeScript.

[kirkwaiblinger]

Marking as blocked on someone filing an issue on TypeScript.

Posed a question in the TS discord to start 👍 (see https://discord.com/channels/508357248330760243/640177429775777792/1247058925401149482)

[sandersn]

This behaviour is intended in Typescript, to allow constant values to initialise mutable ones:

const start = 1001;
const max = 100000;
// many (thousands?) of lines later ...
for (let i = start; i < max; i = i + 1) {
  // did I just write a for loop?
  // is this a C program?
}

(From https://github.com/microsoft/TypeScript/wiki/Reference-Checker-Widening-Narrowing#literal-widening)

The best way to write this, in my opinion, is @kirkwaiblinger's second suggestion -- although it would be even better if Typescript allowed as const on object properties.

Even better, if the program allows, is to use "marker" everywhere instead of extracting to a const variable. The compiler checks "marker" everywhere Data is used from here on out, so there shouldn't be a problem with typos which I guess is one reason for extracting to a variable.

I don't know the specifics of no-unnecessary-type-assertion, but I guess that preferring as const on mutable locations instead of immutable ones means that it's currently correct and doesn't need to change.

[kirkwaiblinger]

@sandersn Many, many thanks for the excellent explanation and also the helpful reference to the typescript wiki! 🙏

This info also helps us simplify the repro considerably:

const freshMarker = 'marker';
let mutableMarker = freshMarker;
const notAssignableDueToWidening: 'marker' = mutableMarker; // TS ERROR - can't assign string to 'marker'

vs

const unfreshMarker = 'marker' as const; // TYPESCRIPT-ESLINT ERROR - no-unnecessary-type-assertion
let mutableMarker = unfreshMarker;
const assignable: 'marker' = mutableMarker; 

---

It's not immediately obvious to me what the best behavior for the rule would be in light of this info.

In theory, it might make sense to update the check to be: if the type before and after the assertion are the same and it's not in a context in which freshness could be impacted, consider it an unnecessary type assertion.

Seems there's also a good argument that usually the freshness/unfreshness isn't necessary or desired, so from a developer perspective this probably is an unnecessary type assertion in most cases, albeit not one that behaves identically after removing (and therefore which may need to be disabled when the unfresh behavior is genuinely desired).

@typescript-eslint/triage-team

[kirkwaiblinger]

Note also that re-allowing

const three = 3 as 3;
// or, maybe selectively allowing this version
const four = 4 as const;

would basically amount to relitigating #4485 and #8458 (as noted by @ashvinsrivatsa when pointing out that this presumably changed with #8558)