[API Question] Only `x` and `y` types getting switched after updating

[AnyhowStep]

Just a curious observation.

I was on TS 3.3.0-dev.20181129. Then, I discovered a bug and was about to file a report but realized it was fixed in 3.3.0-dev.20190103.

So, I updated. After updating, about half of my compile-time tests (190 files) started failing, because the compiled output is now different. No biggie. I expected this to happen. Probably characters getting shuffled around, since I do a character-by-character comparison.

I looked at the diffs and it looks like most, if not all, are some variant of the following,

It's just anywhere with x, and y gets switched. So far, it looks like all other fields/string literals do not get switched around.

I wouldn't be so confused if all fields were getting swapped around, somehow. Or if things were getting randomly shuffled. But it looks like it's only x and y.

I have some objects where the fields are a, b, c, etc. but only x and y seem to be flipped. (I'll stop repeating myself ad nauseam)

---

Does anyone have any insight as to why it's just those two characters and nothing else?

[AnyhowStep]

Slightly longer string with only x and y switched.

I've also seen something like,

{ x : SomeTypeA }|{ y : SomeTypeB }

become,

{ y : SomeTypeB }|{ x : SomeTypeA }

So, even objects containing x and y, in a union type get switched.

---

[EDIT]

Even longer,

[AnyhowStep]

I added a few new tests without modifying the original tests and it switched the x and y of all the other 190 files back to how they were before ._.

I'm guessing it's a duplicate of #29146, which I opened before but, in this case, something changed between the two versions that just acted weird =/

[AnyhowStep]

Actually, maybe it's slightly different. Before, it was always a small number of files, and object properties wouldn't get switched. This one had them flipped. I'm sure it's related to the other question but I'm not 100% sure.

[weswigham]

Definitely still #29146 - union order is solely determined by the order the types were originally materialized in the checker. It's entirely possible that somewhere we now find a something the necessitates making a "y" type before a "x" one.

TBH, I'd prefer if string literal types were sorted lexicographically... maybe we can change how their IDs are assigned to support that...

[AnyhowStep]

All right, thanks for clarifying! ><

Maybe I should use something other than character-by-character diffs