Distribute index over mapped types when normalizing types

[Andarist]

fixes #54892

[typescript-bot]

Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page.

Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up.

[Andarist]

This is an attempt to fix this issue, a conversation starter to establish the proper fix 😉

The core of the issue is that with this code:

function run<T extends Table>(pointer: Pointer<T>) {
  const x = something(pointer);
}

the indexed mapped type gets substituted and thus source in isRelatedTo quickly becomes { table: T; id: string; } because T isn't a union (so It's not handled by distributeIndexOverObjectType), it just has a union constraint.

On the other hand, this version has no real semantic difference and yet it's handled correctly:

function run<T extends Table>(pointer: Pointer<T & Table>) {
  const x = something(pointer);
}

This is because this added intersection creates a union here so distributeIndexOverObjectType kicks in and we end up with: { table: T & "a"; id: string; } | { table: T & "b"; id: string; } | { table: T & "c"; id: string; }.

And because this is a union, ' eachTypeRelatedToType' can relate this with Pointer<keyof TableToRecord> (also a union). The broken case though can't be related through typeRelatedToSomeType because its table property is of type T with a constraint of 'a' | 'b' | 'c' where we have 3 targets with the table property respectively set to 'a', 'b' and 'c'.

I've tried a couple of things, deferring this indexed access type, etc. It seems though that during inference we actually want to perform this substitution, we don't necessarily want to do it when relating types. So if this is meant to be fixed this function here has to conditionally do different things with those indexed mapped types - based on the usage type.

[weswigham]

Hm, not a huge fan of a conditional check like this in getSimplifiedType - this may be a case where this should basically be a new relationship rule, since it's both only being done inside relationship checking, and only being done on the source side type. All that seems to indicate this equivalency would be better recognized as a new branch when comparing types. We might need to look at the pre-simplified types to make it happen, though.

[weswigham]

Maybe D -> Distributive here, if this gets kept.