Repository navigation
When relating object literal types to unions, avoid elaborating on Array/ReadonlyArray #25750
Description
From Adam Rackis (@arackaf):
Notice that when comparing an object literal against MutationSubscription | MutationSubscription[], it picked the last branch which is bad.
Kind of like #24776, but here if the type originates from an object literal (or from JSX attributes?), we should avoid matching against Array or ReadonlyArray
Activity
arackaf commentedon Jul 18, 2018
Thanks for adding this. But it seems that even when running this same code without type annotations, VS Code still freezes up, and plugins stop responding. But what’s interesting is that this problem ONLY happens (both against typings, and with un-typed code) when the run method pictured is an in-line fat arrow.
If you set it to a variable defined elsewhere, or null, or a method syntax function, it works fine. But Code hates having a fat arrow in that specific position.
DanielRosenwasser commentedon Jul 18, 2018
This was just me noticing you're getting a misguiding error message. 😄
arackaf commentedon Jul 18, 2018
Daniel Rosenwasser (@DanielRosenwasser) - thanks a ton for adding it. These problems seem to always be more complex than they appear at the surface to me - I was only trying to make sure to give all the details of this.
So would the problem you describe above also manifest itself (ie VS Code's plugins becoming unresponsive) if the methods I'm calling, buildQuery above, was set to
any?DanielRosenwasser commentedon Jul 18, 2018
Separately from the problem you're seeing, we're just giving a bad error message.
arackaf commentedon Jul 18, 2018
I don't know - this gets weirder the more things I test. If I take that same syntax, and put it in a separate TS project that does not have my typings, TS accepts that syntax just fine - it doesn't care about the arrow function in that place.
In my other project with those typings, that basic syntax structure causes massive problems, even if untyped, even if the run method is called runX, for example. It seems those typings are making tsc seriously angry anytime it comes across an arrow function in that position in JSX.
cc Mohamed Hegazy (@mhegazy)
arackaf commentedon Jul 18, 2018
Sorry to add so much spam to this issue. It seems even deleting my typings file completely, still causes this JSX to lock VS Code up, with it falsely reporting an error for a good 30 or so seconds. It happens as soon as, and only when I, put the arrow function there.
I confirmed the typings were gone, and VS Code was in fact reporting these members as
any. I'm a bit hesitant to publish this library with TSC hating it so much :)Has the cause of this been found yet? Is there anything I can do to help reproduce it?
/cc Mohamed Hegazy (@mhegazy)
DanielRosenwasser commentedon Jul 18, 2018
It's going to take some time to investigate the problem that you were running into without a minimal repro. This issue really is only about giving a better error message in specific cases (which you can see an example of in #25752).
Yeah, I would recommend not publishing with
.d.tsin the meantime then if it's going to cause users a lot of pain.