Enhancement: [array-type] Detect Readonly<string[]>

[neelance]

Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/array-type

Description

The rule should also turn Readonly<string[]> into readonly string[].

Fail

const y: Readonly<string[]> = ['a', 'b'];

Pass

const y: readonly string[] = ['a', 'b'];

Additional Info

No response

[bradzacher]

Is this a common pattern you've seen around your codebase?

[neelance]

Yes, we had a few of them. This is because we have another linter rule that enforces immutability on certain types. I guess this is why people started adding Readonly<...> also to array types.

I have now used no-restricted-syntax to detect this pattern. Still, it seems to me like it would make sense to add this to array-type. I was a bit surprised that it wasn't included.

[JoshuaKGoldberg]

Enforcing Readonly<...> vs. readonly ... is covered by https://github.com/eslint-functional/eslint-plugin-functional/blob/e4bd4ad79502ff77ae26e703e1761ab80a46868b/docs/rules/prefer-immutable-types.md and https://github.com/eslint-functional/eslint-plugin-functional/blob/e4bd4ad79502ff77ae26e703e1761ab80a46868b/docs/rules/type-declaration-immutability.md (previously, https://github.com/eslint-functional/eslint-plugin-functional/blob/e4bd4ad79502ff77ae26e703e1761ab80a46868b/docs/rules/immutable-data.md). That's a separate concern from the Array type styles.

If folks have already started adding Readonly<...> to types and are enforcing immutability on certain types, then I bet https://github.com/eslint-functional/eslint-plugin-functional and/or https://github.com/jhusain/eslint-plugin-immutable are plugins you all might find useful (if you haven't already started using them).

Thanks for filing!

[Josh-Cena]

@JoshuaKGoldberg To clarify: this issue asks for the rule to check that readonly array types are declared consistently, not that they are marked as readonly. Do those rules cover this use case?

[JoshuaKGoldberg]

Yeah I think this rule shouldn't cover that case because Readonly<...> isn't specific to arrays, and users often end up writing their own equivalents (ReadonlyDeep, etc.). Trying to expand this rule's purview to the assorted wrapper types folks use would make its area of responsibilities more than just array types.

[Josh-Cena]

This rule already checks between readonly T[] and ReadonlyArray<T>. It's not unreasonable to me to expect Readonly<T[]> to work. But maybe this would be confusing to some users, I don't know.

[JoshuaKGoldberg]

I think the difference (for me at least) is that ReadonlyArray is a built-in dedicated array type, whereas Readonly is general.

[bradzacher]

I would say that we can easily include this case because it's syntactically simple to detect the case of Readonly<T[]> - the developer intent was clear - they wanted a readonly array and there are true constructs for that - so we can improve codebase consistency by reporting and suggesting the configured style instead.

I'm in favour of this, personally!

[JoshuaKGoldberg]

Well, I guess I'm being outvoted on this one 😄