[Feature request] sort literals in .d.ts

[bluelovers]

Search Terms

Suggestion

sort string literal in .d.ts

Use Cases

avoid string literal random change order when source code didn't change
and make code history is more easy read

in this issue thread string literal is mean => "a" | "c" | "b"

this not only happen on Record, it has chance happen at all type is auto create by typescript emit with string literal

Examples

"a" | "c" | "b" is create by typesctipt emit and some time will random change order

• https://github.com/bluelovers/cjk-convert/blob/1a0ba9f85e0bf7fe916158cc14a4ef87507106d9/lib/zh/table/table.ts#L1619-L1635
• output declaration type random change order #30328
  • bluelovers/novel-travis-test@3b88745#diff-3006c96d8657ccca5b9b3618a256314c
  • bluelovers/novel-travis-test@d33c4a6#diff-3006c96d8657ccca5b9b3618a256314c
  • bluelovers/novel-travis-test@2d74919#diff-3006c96d8657ccca5b9b3618a256314c

current .d.ts output

---

export declare const table_plus: Record<"a" | "c" | "b">
// "a" | "c" | "b" is random change order

in this request

sort ( use simple array.sort() ) it when output emit at .d.ts

export declare const table_plus: Record<"a" | "b" | "c">

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Maintainer's note [@sandersn]: To implementers: When you implement this, be sure to sort other literal types too. Consider sorting other things, like symbol, by the order of their string representation.

[AnyhowStep]

Related: #29255

If you implement this, you'll break my compile-time tests again =(

[fatcerberus]

This is labeled good first issue, yet I seem to remember another issue talking about how union order isn’t guaranteed (it’s based on an internal ID number for each type) so that there was basically nothing that can be done about this without major architectural changes and/or performance issues...?

[sandersn]

@fatcerberus This is just requesting that d.ts emit sorts the union right before printing it. It wouldn't affect the checker itself.
Should be fine, except for evil corner cases like the UnionToTuple type, which manage to export the internal ordering into another type.

@AnyhowStep but then it would be the last time???

[AnyhowStep]

Oh, right. I hecked up.

[tp]

I see a consistently different sorting with the same TS version using tsc and tsc -w.

Would this also be fixed by this change, or should I write a separate report?

[sandersn]

@tp It's almost certainly the same, since that difference is probably from types getting created in different order for tsc -w and getting assigned different type ids.

[AnyhowStep]

If we're sorting string literals, can we also sort all the other literal types?
number, bigint, boolean.

Maybe even unique symbols.
typeof b | typeof a should be typeof a | typeof b.

I just had another compile-time test break because the order of execution caused some union type to switch elements around.

[sandersn]

@AnyhowStep good idea