🚀 Feature: Normalize union ordering and readonly array syntax

[JoshuaKGoldberg]

Bug Report Checklist

• I have tried restarting my IDE and the issue persists.
• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

Splitting out from microsoft/DefinitelyTyped-tools#858 (comment): @definitelytyped/expect internally "normalizes" commented types by creating a virtual source file with a type annotation, then stringifying the type annotation. https://github.com/microsoft/DefinitelyTyped-tools/blob/3d6c2ffd0b38eac222e03156c3d62d6020b2b94b/packages/eslint-plugin/src/rules/expect.ts#L492

That feature is particularly useful for when you have multiple TS versions (#107). It's also generally nice to be a little less nitpicky for users (see also: #18). Let's take that feature in here!

Additional Info

No response

[jakebailey]

I will note that our existing normalization both before and after are imperfect, specifically for readonlyness. It's totally possible for someone to have declared a type named ReadonlyArray and it conflict such that an expect passes, but the risk seemed quite minimal.

Union sorting should be fine, though it does have a perf cost (that is avoided on exact matches).

[danvk]

For union ordering specifically, there's some code (and tests) you could grab from literate-ts:

https://github.com/danvk/literate-ts/blob/e6f91f2e15ce59d915fb0f4c08d68a656c32e7e4/src/ts-checker.ts#L367-L388
https://github.com/danvk/literate-ts/blob/e6f91f2e15ce59d915fb0f4c08d68a656c32e7e4/src/test/ts-checker.test.ts#L509-L555

[jakebailey]

I would recommend not parsing any type strings without calling TS's parser; this kind of code wouldn't handle string literal types containing | (which is why I did it differently in the rule for DT).