Use a consistent ordering when writing union types

In DefinitelyTyped, $ExpectType assertions depend on a type having a consistent string represenation across TypeScript versions.
It looks like the ordering of union types is dependent on some implementation details that change between versions. When we output unions as strings, we should sort them in some consistent way first instead of just using whatever order we happened to use internally.

I would suggest this ordering:

• numeric literals, low to high
• string literals, low to high (by <)
• named types (including type aliases, enum, class and interface names), by name
• function literals: by length (() => void before (x: number) => void), then by parameter name, then by parameter type
• type literals: Sorted smallest to largest ({ x: number } before { x: number, y: number }); and type literals of the same size should be alphabetically sorted by property ({ a: number }) before { b: number }) or by the sorting of values ({ s: "a" } before { s: "b" })

Of course, another solution would be to try to handle this in $ExpectType by parsing out unions and allowing it if any sorting is valid. But it is strange in TS to see a string literal union displayed in a seemingly random order.

[DanielRosenwasser]

While I understand the I understand the frustration, I don't think this is a good idea from a user perspective. Why would you want the user to have to memorize the rules for union type ordering?

In my opinion, you can go one of two paths:

1. The tool should be user-friendly enough and perform its own sorting.
2. Introduce a snapshot-based approach where users can accept baselines.

Additionally, I'm not sure how bullish I am on the idea of committing to a specific ordering.

The goal isn't for users to memorize the ordering, the goal is for our output to be consistent across versions to that we can run the same tests against multiple versions. A baseline approach would be a bad idea as currently the ordering could change in nightly builds, which could cause hundreds of breaks in DT tests if we do something that changes the order of type creation.
I've created microsoft/dtslint#61 to clean up the test failures for now, could you review?

[RyanCavanaugh]

I'm with Andy on this one - we get "bug" reports because people don't understand why the order in quick info isn't the same order they wrote (e.g. you can write A | B and you'll sometimes see B | A). Being able to explain why that order is, rather than "It's arbitrary, so ... ??" would be preferable.

There's also the problem of devs on the same time with slightly different compiler versions emitting .d.ts files and constantly generating false diffs - because we don't guarantee this ordering at all, even patch versions could cause this behavior.

[Blasz]

There's also the problem of devs on the same time with slightly different compiler versions emitting .d.ts files and constantly generating false diffs - because we don't guarantee this ordering at all, even patch versions could cause this behavior.

I'm running into this issue right now. We have a process that diffs our d.ts files to test against any changes as part of build refactors. This is generating false positives because of the union order not being idempotent, regardless of compiler versions.

Is there any update on this? Based on this comment #13298 (comment) it seems like this isn't possible to implement?

[AnyhowStep]

#32224