Union type assertions shouldn't care about the order

[benlesh]

We've hit an issue in the RxJS dtslint tests where a test is trying to assert:

const o = from([of(1), ['test'], iterable]); // $ExpectType Observable<IterableIterator<number> | Observable<number> | string[]>

And dtslint complains it wants Observable<Observable<number> | IterableIterator<number> | string[]>, but if you change it to that:

const o = from([of(1), ['test'], iterable]); // $ExpectType Observable<Observable<number> | IterableIterator<number> | string[]>

... then it complains that you should change it back.

It seems like this is the wrong behavior: a | b | c is no different than c | b | a, AFAICT. ... but perhaps I'm wrong?

Thank you in advance for your help.

[cartant]

Related but closed: #61

[SgLy]

I am having the same problem. dtslint reports that $ExpectType 1 | 2 but got 2 | 1 and gives me an error.

[ersimont]

I am hitting this issue. When I make certain changes to my production .ts files, dtslint suddenly changes the expected order of many union types in unrelated files, causing many of their typing tests to fail.

Either order should not matter for unions (as the title of this issue suggests), or the order should remain stable. As it is, I can't figure out how to add the new function I want to my library without updating ~70 type expectations. And then what if the next function I add swaps them back?

[ersimont]

I made a branch on micro-dash to demonstrate the issue. To reproduce:

1. Check out the branch dts-union-swap
2. yarn install
3. yarn dtslint - everything passes
4. Uncomment the contents of projects/micro-dash/src/typing-tests/at.dts-spec.ts
5. yarn dtslint - many errors because the ordering of unions changed

[thw0rted]

There seems to be a large class of errors that stem from the fact that, while expectType (from tsd) takes an actual "type-space" generic param as the expectation, the dtslint $ExpectType does simple string matching:

#57
#114
#352

Would it be better to just transition to using tsd tests instead of the comment-based syntax? (I'm not that familiar with the ecosystem, I assume the dtslint implementation has some kind of advantages over tsd...)

[thw0rted]

Very interesting: I just found DefinitelyTyped/DefinitelyTyped#60016. Until that edit, I didn't realize that an or-operator (||) worked in $ExpectType -- if it's documented anywhere, I couldn't find it. So, I guess one workaround for this issue, if you have a small union, would be $ExpectType A | B || B | C. (In that PR, it's used to handle different versions of TS ordering the union in question differently.)