`as` type assertion fails for `ReadonlyArray<T>` but succeeds for `T[]` with identical object literal

[raymondwang]

🔎 Search Terms

• ReadonlyArray assertion
• readonly array type cast
• sufficiently overlaps readonly

🕗 Version & Regression Information

• This is the behavior in every version I tried (tested in 3.5.1, 5.9.3, and nightly)

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.9.3#code/JYOwLgpgTgZghgYwgAgJKQLbIN4ChkHJQRwAmA9iADYCeywpAXMgM5hSgDmA3PocWUq1kVOACMIVZmw4hOyAD7IQAVypVeAX1y5QkWIhQBZFWHFUI6CBhY4+BARWp1gmFsysYA2gF1FytQ1cbV1waHgkZAAlEidaT1s8QiJYoRc3ZhjBZwBBKCg4GgAeTwA+f1V1LR0ESjZkDHIEAGsTMzELBOQAXjtk12t3ZC97ZL6xiYZmAHIARmmAGlHkzSXknyXNZDhbNvNLN15cWpB6xpasuJou3qTCAZtmEYmCO5f7pmRpgCZF5cJVqMNsFtrZLmkEtwgA

💻 Code

interface Item {
    readonly id: string;
    readonly label: string | null;
}

interface MutableItems {
    readonly items: Item[] | null;
}

interface ReadonlyItems {
    readonly items: ReadonlyArray<Item> | null;
}

const mockMutableItems = {
    items: [
        {
            id: '1',
        },
    ],
} as MutableItems;

const mockReadonlyItems = {
    items: [
        {
            id: '2',
        },
    ],
} as ReadonlyItems;

🙁 Actual behavior

mockReadonlyItems produces error TS2352:

Conversion of type '{ items: { id: string; }[]; }' to type 'ReadonlyItems' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
  Types of property 'items' are incompatible.
    Type '{ id: string; }[]' is not comparable to type 'readonly Item[]'.
      Property 'label' is missing in type '{ id: string; }' but required in type 'Item'.

🙂 Expected behavior

Both assertions should behave consistently. Since the mutable Item[] version allows the assertion (correctly recognizing that as is an intentional type override), the ReadonlyArray<Item> version should also allow it.

Additional information about the issue

Other observations:

• as const satisfies errors consistently, which seems good
• Omitting items from mockReadonlyItems removes the associated type error, suggesting that the issue is specifically when trying to assert on a defined ReadonlyArray

[Andarist]

The underlying cause is the same as here:

type Source = {
  a: { c: 1 };
  b: 3;
};

type Target = {
  a: { c: 1; d: 2 };
};

declare const source: Source;

const test = source as Target; // error because `a` is incompatible
const test2 = source.a as Target["a"]; // but yet this is ok

Notice that both source and the target have unmatched properties on different levels~ (Target is missing b when compared to the Source and Source['a'] is missing d when compared to Target['a']).

This issue is a little bit related to #62177

[RyanCavanaugh]

Type assertions are only allowed when the asserted type subtypes or supertypes the expression type; this behavior is intentional. This is to prevent manifestly-wrong assertions like [1, 2, 3] as number. It's not expected that any two close-ish types should behave identically, since one might be a sub/supertype of the expression type and the other not.