GeezerVison

I think we could discuss some issues with string literals with widening semantics. If you'd like, I'll look into what a widening approach would look like based on our earlier conversation.

Daniel Rosenwasser (@DanielRosenwasser) I've looked at it - string literal types just have to be contextually typed. Mostly because (unlike predicate types) they can appear inside arrays and object literals... and in all those cases we want them to widen away... except when we don't because there's a type annotation on the thing the literal is getting assigned to. And thus the contextual type is born - informing the type of the RHS by the type defined on the LHS side.

So, my real issue: I want to run checkExpression but where the RHS can be contextually typed to a string literal type. I guess that means adding a case for EqualsEqualsEquals to getContextualTypeForBinaryOperand, where it returns a string literal type for the RHS side if its a string literal, or its type instead.

Wesley Wigham (@weswigham) I think #6196 is the answer to your first TODO 😃

Is this now fixed by #8010?

Is this now fixed by #8010?

Nope.

type Action = { type: "REQUEST" } 
            | { type: "SUCCESS", data: string } 
            | { type: "FAILURE", error: any }

let action: Action;
if (action.type === "REQUEST"){
  let inside = action; // Still `Action`
}

Tested with alm just to be sure 🌹 :)

I probably need to rework this PR, #8010 heavily modified the type guard code.

I think I've mostly reconciled the work in this PR with master and the control-flow based type guards therein. Additionally, the bug I had with the code in the emitter is gone now, so that's nice. It feels like it works more cleanly now that CFA-based guards are in. I've updated the OP to match current progress.

Daniel Rosenwasser (@DanielRosenwasser) There's a change to the compatibility relationship test baselines (which have this kind of comparison in them) - I'm not 100% sure what the desired behavior there is, do you want to look at it?