Immutable-By-Default Flags

Search Terms

readonly, default

Suggestion

Adding flags under the strict umbrella to default to immutability in different cases, and a new mutable keyword.

Use Cases

I’m creating this issue as a parent issue to track a couple of issues that already exist for specific cases:

• Class methods: https://github.com/microsoft/TypeScript/issues/22315, https://github.com/microsoft/TypeScript/issues/22315#issuecomment-400708470 in particular
• Arrays: https://github.com/microsoft/TypeScript/issues/32467
• Interfaces: No issue yet, left a comment in https://github.com/microsoft/TypeScript/issues/32467#issuecomment-519333922

Off of the top of my head, these flags would have some direct advantages:

• They clearly state the intention of the whole project in regards to mutability
• It’s very common for new members of teams to forget to add the readonly keyword or use T[] rather than ReadonlyArray<T> accidentally. Defaulting to immutability would help prevent these accidents, and a mutable keyword would be easy to find by tslint or even a simple grep, to automatically request review in PRs or leave an automated comment this PR introduces mutation.

Examples

Examples should probably live in the children GitHub issues, but I’m copying here my comment for a quick example:

interface T {
  n: number // immutable
  mutable s: string // mutable
}

const o: T = {
  n: 42,
  s: 'hello world',
}

o.n = 43 // error
o.s = '👋🌎' // ok

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, etc.)
• This feature would agree with the rest of TypeScript’s Design Goals.

Backwards Compatibility

@AnyhowStep made an interesting comment on this issue.

Basically this feature wouldn’t be any problem for applications, but it could be problematic for libraries, as the emitted .d.ts may be imported from a library/application that isn’t using this flag or is using an older TS version.

Possible solutions:

• A pre-processor directive (https://github.com/microsoft/TypeScript/issues/32758#issuecomment-569369439)
• Always emitting d.ts with readonly, never mutable (possibly behind another flag?)
• downlevel-dts

Records and Tuples

The Record and Tuple proposal has reached stage 2, so it may be arriving to TS soon-ish. It seems closely related to this issue, but I don’t think it fully addresses it.

readonly interface

The possibility of using the readonly keyword for an entire interface has been suggested in A cheaper, easier to implement middle ground could be https://github.com/microsoft/TypeScript/issues/21152.

readonly interface State {
    prop1: string;
    prop2: string;
    ...
    prop22: string;
}

This would probably be a much cheaper and less disruptive feature to implement, and could be a great starting point.

[lautarodragan]

Why not a lint rule where readonly is always required?

And if they want stuff to be mutable, add eslint-disable-next-line.

Not much to say about methods, though.

Three reasons:

• The way one writes affects the way one thinks. It’s harder for new team members to get into the immutability mindset if everything’s mutable by default, specially if they are relatively new to TypeScript.
• One less thing to pay attention to, less cognitive overhead.
• Just did a quick search, there are 179 occurrences of the word readonly in one of the projects I work on daily, and it’s a relatively small codebase. And it’s just one project, we have a few.

[AnyhowStep]

Why not a lint rule where readonly is always required?

And if they want stuff to be mutable, add eslint-disable-next-line.

Not much to say about methods, though.