question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Use a consistent ordering when writing union types

See original GitHub issue

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.

Issue Analytics

  • State:open
  • Created 6 years ago
  • Reactions:13
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
RyanCavanaughcommented, Aug 22, 2017

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Using different order by with union - Stack Overflow
In a query that uses UNION, EXCEPT, or INTERSECT operators, ORDER BY is allowed only at the end of the statement. This restriction...
Read more >
PEP 604 – Allow writing union types as X | Y
This PEP proposes overloading the | operator on types to allow writing Union[X, Y] as X | Y , and allows it to...
Read more >
Union declaration - cppreference.com
Union declaration ; Expressions ; Value categories · Order of evaluation · Operators · Operator precedence ; Alternative representations ; Literals.
Read more >
Structure and union type definition - IBM
A structure contains an ordered group of data objects. Unlike the elements of an array, the data objects within a structure can have...
Read more >
A Gradual Interpretation of Union Types - PLEIAD
understand gradual typing, we present a novel design for union types, ... The same program can also be written using implicitly-tagged unions with...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Hashnode Post

No results found