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

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.

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!

@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?

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.

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.

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

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!

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

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

I just stumbled upon this in one of our projects and was very confused that it's not caught by the array-type rule. Can confirm that it happens. 😅