String literals not contextually typed within jsx attributes #19041

Activity

1. Mohamed Hegazy (mhegazy)

   added

   BugA bug in TypeScriptA bug in TypeScript

   on Oct 9, 2017
2. Mohamed Hegazy (mhegazy)

   assigned

   Wesley Wigham (weswigham)

   on Oct 9, 2017
3. Mohamed Hegazy (mhegazy)

   added this to the TypeScript 2.7 milestone on Oct 9, 2017
4. weswigham commented on Dec 14, 2017

   

   Wesley Wigham (weswigham)

   on Dec 14, 2017

   MemberAuthor

   More actions

   This is just a quirk of how getTypeAtLocation works, and applies to both object literals and JSX.

   For example, in:

   // @jsx: preserve
   
   namespace JSX {
       export interface IntrinsicElements {
           span: {};
       }
       export interface Element {
   		something?: any;
       }
   }
   
   const Foo = (props: { foo: "A" | "B" | "C" }) => <span>{props.foo}</span>;
   
   Foo({
       foo: "B"
   });
   
   <Foo foo="B" />

   In both calls to Foo, the property foo has its type baseline printed as string - the widened type of the initializer - despite that not being the contextual type (which is "A" | "B" | "C") or the inferred type for that member of the object (which is "B"). The top-level object type is built correctly, since it doesn't use getTypeOfSymbol - it uses checkPropertyAssignment on each property, which defers to checkExpressionForMutableLocation instead. It looks like using getWidenedTypeForVariableLikeDeclaration outside of checkVariableLikeDeclaration is highly suspect (since it is being expected to handle more kinds than it does). This disproportionately affects JSX baselines, since they have no top-level JsxAttributes object type baselines to inspect for correctness and more frequently have literal-typed properties (at least in our own baselines).

   This is probably worth fixing, if only to make life easier for our API consumers and our type baselines actually correct, but should also make quick info accurate on JSX attributes (property assignments are already accurate, so they're likely using a special secondary code path somewhere...). Fixing this has also exposed how we don't handle literal widening on jsx attributes correctly (or at all).
5. Wesley Wigham (weswigham)

   closed this as completedin #20706on Dec 15, 2017
6. Mohamed Hegazy (mhegazy)

   added

   FixedA PR has been merged for this issueA PR has been merged for this issue

   on Jan 9, 2018
7. microsoft

   locked and limited conversation to collaborators on Jul 3, 2018