[Feature request] sort literals in .d.ts
Opened this issue · 9 comments
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
- #30328
current .d.ts output
export declare const table_plus: Record<"a" | "c" | "b">
// "a" | "c" | "b" is random change orderin 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.
Related: #29255
If you implement this, you'll break my compile-time tests again =(
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...?
@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???
Oh, right. I hecked up.
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?
@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.
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.
@AnyhowStep good idea