Closed
Description
- More API exposure per our own "bundler" requirements Export internal functions needed by dtsBundler.mjs #52941
isDeclarationStatement
,isInternalDeclaration
nullTransformationContext
- Why isn't this the behavior under
undefined
? - Could try
- Check with Ron
- Why isn't this the behavior under
isPartOfTypeNode
- Is this function always correct?
- Wasn't always, but is now
- Is
stripInternal
real now?- No.
- OK for 5.4
- Tuple key remapping Can't remap tuple keys to object keys in mapped types #55762
- Mapped type over a type parameter constraint to a readonly array of 2-tuples
- It iterates
[a, b]
to forma: b
- It iterates
- Works as expected with
& ${number}
, but not& number
- This mapped type hits e.g.
indexOf
,"0"
, and thenumber
index signature- Correct? Desirable?
keyof
needs to behave consistently between Array and Arrayish objects- But in homomorphic mapped types, the output is still presumably an array, so we don't need to mess with Array methods in that case
- What we "need" is a different mapped/keyof/whatever syntax to force homomorphism in mapped types
- But this is a pain, and confusing
- Why
${number}
is needed?- This is the bug re: the implied constraint in the
as
clause - You'll still need something to avoid the numeric index signature
- This is the bug re: the implied constraint in the
- Mapped type over a type parameter constraint to a readonly array of 2-tuples
- b i v a r i a n c e Class parameter incorrectly treated as bivariant #56225
- What to do when a type parameter only appears in the test position of a conditional type?
- We currently (arbitrarily!) treat it as bivariant, for bad and confusing reasons
- This falls out of the variance measurement process, which doesn't have a good mechanism to relate
infer
outputs - Conditional types are for creating non-varying relations, which wrenches the whole process
- This falls out of the variance measurement process, which doesn't have a good mechanism to relate
- We currently (arbitrarily!) treat it as bivariant, for bad and confusing reasons
- If this were a lookup type, we could figure out this was covariant, but there's no lookup syntax for a return type
- Creates further confusion since it's not always obvious if a structural or variance-based relation is occurring
- Marking all
extends T
-> unmeasurable onT
is fairly catastrophic for performance- Also messes with signature relationships
- Confusing since
InstanceOf
is covariant on part of the type; even if variance annotations were allowed here, they'd be wrong - What to do?
- Try a PR and see if it's maybe OK now
- ???¿??
- What to do when a type parameter only appears in the test position of a conditional type?