It works for most things - the cases it doesn't support are rarer. Do you have an example of a type that isn't possible to make readonly?

Whilst we don't explicitly mention it - it is definitely strongly implied by the allow option which allows you to ignore specific types from libraries.
https://typescript-eslint.io/rules/prefer-readonly-parameter-types/#allow

It works for most things - the cases it doesn't support are rarer. Do you have an example of a type that isn't possible to make readonly?

Whilst we don't explicitly mention it - it is definitely strongly implied by the allow option which allows you to ignore specific types from libraries. https://typescript-eslint.io/rules/prefer-readonly-parameter-types/#allow

Well, I don't understand how I can safely make all properties in an external interface readonly. Won't it break anything? I believe that allow solves the issue, but it's very painful to add all external libraries to this option. And there isn't a single word about DeepReadonly or something.

And I don't understand why it doesn't work in these cases

@ddubrava please don't send screenshots of code - first of all other users cannot find their content in search and second of all nobody can reproduce your issue from a screenshot without hand-typing all of the code.

Instead - use our playground - https://typescript-eslint.io/play/

@ddubrava please don't send screenshots of code - first of all other users cannot find their content in search and second of all nobody can reproduce your issue from a screenshot without hand-typing all of the code.

Instead - use our playground - https://typescript-eslint.io/play/

I'm sorry, didn't know about the playground.

https://typescript-eslint.io/play/#ts=5.1.6&fileType=.tsx&code=C4TwDgpgBAIhFgEoQIYBMD2A7ANiAPACoB8UAvFIVBAB7ARZoDOUAFAJZYBmEATlIgCUAbQC6AKChQA-LHhJUmXCACCvXigKJikqAC5K1Og2ZQAYgFcsAY2Dtsu2YV0GqteoxYYARgCsIto5yCMjo2HgA8n4BwEQ6Uq4A3OLinPS8XCjW0HAhiuGq6ppxRh6moUp4ahoEuQphynGkAN5QAL4poJDB9ZUgUf62JRTNurz5ylDCAApQnFAA1hAgGFyUogZ1FQVEM6LEyW3J4gD0J1AAjOJcVrb2WOYYGKwA7pyb8tuNAOqcmC-EQRQUZSazYJgYHAQAB0OAwAHNXpxBIcUmcoAAmcS0MAYXjAKA3Gx2bDULDAXjsCBMQgYAYxfAAaWWpRMLGmvAwkHxIGZIAANFAAGooHAWCDEVi6BgUqlMD55Bp4fDCPmCkViiCiMTEfniQQGZBg3hoJnLdWi8UtMYQYAWXgPGWU6mo07nADMgvYa3QaB6XzwUFJqGsAAsoFCAG4QHBeglvHA4KAvPELaFQN1QbwWAnsAmYalYADkBIAtigllAUFgQFAmAx6%2BIwVgmAT6K2AMIoevy-0TZVGvGm1uUrDwwUjzjw4hiHXkKaiY7t4BdnvQrh4gCiWVDrFYwhQgu8oiBZGtUlB4MhMLhiMPWZRF4zUjaepR4iAA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6Y6RAM0Wls4CGAEwD2TeIVrEB0AQFtE%2BXrSKlUGSL2gjokcGAC%2BIA0A&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

type DeepReadonly<T> = T extends (infer R)[]
  ? DeepReadonlyArray<R>
  : T extends Function
  ? T
  : T extends object
  ? DeepReadonlyObject<T>
  : T;

interface DeepReadonlyArray<T> extends ReadonlyArray<DeepReadonly<T>> { }

type DeepReadonlyObject<T> = {
  readonly [P in keyof T]: DeepReadonly<T[P]>;
};

// 1
function Foo(win: DeepReadonly<Window>) {
  console.log(win);
}

// 2
export function entriesToObject<Key extends PropertyKey, Value>(
  entries: DeepReadonly<[Key, Value][]>,
): Record<Key, Value> {
  return entries;
}

// 3, if add DeepReadonly on each level, it will work. 
// but it doesn't make any sense
const testCases: DeepReadonly<Record<string, string>[][]> = [];

testCases.forEach(([a, b]) => {
    console.log(a, b);    
  },
);

What I'm trying to convey is that this rule is very difficult to use in a real project. It requires using weird hacks like multiple nested DeepReadonly and configuring the allow property. It makes sense that these hacks are necessary, but I believe we should mention about them in the documentation.

p.s. I tried using another DeepReadonly at the beginning, but it did not fix some errors. So it might be worth adding an example/reference of it to the documentation.

Unfortunately your DeepReadonly utility is not infallible - there are some cases that it cannot truly mark as readonly. As you saw - tuples and arrays it isn't good at.

There are 3rd party options out there - like type-fest which supply the ReadonlyDeep type - which should cover more cases and do a much better job.

However even then there are still cases it won't necessarily get right.

This is the point of the allow option I mentioned earlier - it allows you to configure the rule to ignore certain types that you know are impossible to make truly readonly.

Unfortunately your DeepReadonly utility is not infallible - there are some cases that it cannot truly mark as readonly. As you saw - tuples and arrays it isn't good at.

There are 3rd party options out there - like type-fest which supply the ReadonlyDeep type - which should cover more cases and do a much better job.

However even then there are still cases it won't necessarily get right.

This is the point of the allow option I mentioned earlier - it allows you to configure the rule to ignore certain types that you know are impossible to make truly readonly.

Ok, many thanks for explaining all of this to me. So, don't you think it's worth summarizing this and adding key points to the documentation?

I think it'd make sense to note in the docs:

• Third party types are often not readonly
• Utils such as type-fest can be useful
• The tradeoffs in this thread

I think it'd make sense to note in the docs:

• Third party types are often not readonly
• Utils such as type-fest can be useful
• The tradeoffs in this thread

I can work on this