Nested object spread destructuring doesn't remove readonly-ness

[pschiffmann]

Bug Report

The two functions below behave identical at runtime. However, TypeScript flags the second function with an error.

interface Data {
  readonly nested: Readonly<Record<string, string>>;
}

function updateNested_1(data: Data, k: string, v: string): Data {
  const nested = { ...testData.nested };
  nested[k] = v;
  return { ...data, nested };
}

function updateNested_2(data: Data, k: string, v: string): Data {
  const {
    nested: { ...nested },
  } = data;
  nested[k] = v; // Index signature in type '{ readonly [x: string]: string; }' only permits reading.ts(2542)
  return { ...data, nested };
}

🔎 Search Terms

destruct readonly

🕗 Version & Regression Information

Tested in version 5.0.4.

⏯ Playground Link

Playground Link

🙁 Actual behavior

Since the spread-destructuring creates a copy of the original object, it should lose it's readonly modifier.

🙂 Expected behavior

The spread-destructured object retains it's readonly modifier.

Interestingly, this works already if nested doesn't have an index signature.

[RyanCavanaugh]

Expressions of type { ...x } always have the same type as x. Doing anything else breaks other scenarios in terms of both correctness and performance.

[fatcerberus]

@RyanCavanaugh Hm, that doesn't explain why the behavior differs between updateNested_1 and updateNested_2 though. The former has no error as nested seems to lose its readonlyness.

[pschiffmann]

Expressions of type { ...x } always have the same type as x.

Maybe we're talking about different situations? In TypeScript 5.0.4 (with "strict": true), creating an object with a spread operation removes readonlyness from it's type:

function f(original: Readonly<Record<string, string>>) {
  original.test = "something"; // Index signature in type 'Readonly<Record<string, string>>' only permits reading.ts(2542)

  const copy = { ...original };
  copy.test = "something"; // This is OK, no errors.
}

Playground link

[RyanCavanaugh]

I think I misread the original the first time around. The rules for destructuring and expressions are not necessarily different and are geared toward different inference cases. Behaviors are desirable in certain cases, and it's a zero-sum game of which one gets picked for which, so I don't think there's anything to change here.

[github-actions]

This issue has been marked as 'Not a Defect' and has seen no recent activity. It has been automatically closed for house-keeping purposes.