Allow for entire interface definitions to be marked "readonly"

[Droogans]

Suggestion

Just interfaces. I wanted to request this specifically since it touches a lot of other things that are under discussion in the issue history here.

🔍 Search Terms

#10725 (comment)

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

From the search term linked to above:

---

I would like to be able to do something like this:

readonly interface Foo {
  one: string
  two: string
}

It could be a deep readonly, but I would be ok with it being shallow. Ultimately I'm trying to avoid doing this:

interface Foo {
  readonly one: string
  readonly two: string
}

If someone adds another property, it may not be clear that Foo is supposed to be treated as an immutable type.

---

👏 Interfaces individually should be marked readonly, any extending of it must designate those restrictions themselves. More in use cases.

📃 Motivating Example

Python's frozen dataclasses, with better guarantees

💻 Use Cases

In the effort to strike a good balance between "immutable" typescript and productivity payolffs, I would suggest two options: atomic readonly interfaces (nothing other than that exact interface is readonly) as well as persistent readonly interfaces (like the kinds you get with an ORM).

An atomic readonly interface is bounded to just the one interface, but without marking itself as persistent only other references remain readonly. This is the default.

readonly interface B {
  thisWillNotChange: string;
  evenIfReferencedElsewhere: string; 
}

interface A {
  foo: string;
  bar: number;
  interfaceB: B;  // error: reference to readonly interface `B` must be accessed via a readonly property
  mutableB: abstract B; // ok
}

interface C extends B {
  mutableProperty: string;
}

class Thing implements C {
    // ....
}

thing = new Thing(...foo);
thing.mutableProperty = "other";  // ok
thing.thisWillNotChange = "";  // not ok

An interface which needs mutable properties in B would still be able to do so, with an "abstract override".

interface C extends abstract B {
  // ...
}

readonly interface D extends abstract B {
  // properties defined by B are mutable, all properties in D are readonly.
};

This abstract interface pattern can be used to define a stricter "deep" readonly behavior.

abstract readonly interface ORMData {};

interface ExampleServiceData extends ORMData {
  // error: interface 'ExampleServiceData' must be readonly to extend abstract readonly interface ORMData
};

interface ExampleServiceMetadata extends ExampleServiceData {
  // error: interface 'ExampleServiceMetadata' must be readonly to extend abstract readonly interface ORMData
};

Going all out this way gets you the ability to generate warnings/reports of abstract interface usage (and importantly, overrides of those interfaces), as well as any references that appear later on where this override was actually used.

[MartinJohns]

Related to #42357, #32758.

[ ] This could be implemented without emitting different JS based on the types of the expressions

Why didn't you check this? I don't see anything that would change the emitted JS, it's all purely on the type-level.

[Droogans]

I left "use cases" full of some ideas I had to utilize the abstract keyword as well as readonly in a way that might be a bit much.

The idea is to create some "complement" that can be applied to either the definer or the extender, depending on which "direction" they're going when it's used.