Strange boolean-discriminant narrowing with strictNullChecks off

Description

type Result = { success: true }
            | { success: false, error: string }

function handleError(res: Result) {
    if (res.success === true) {
        return;
    }

    res.error; // OK
}

function handleError2(res: Result) {
    if (res.success !== false) {
        return;
    }

    res.error; // OK
}

function handleError3(res: Result) {
    if (res.success) {
        return;
    }

    res.error; // Property 'error' does not exist on type 'Result'
               // but should be OK
}

Contributor guide

Tech stack

typescript

Domain

developer experience

Issue type

bug

DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.

3

Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.

1-2 days

Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.

stale

ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.

clear

Prerequisites

TypeScript type system understandingKnowledge of control flow analysis

Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.

40

Research direction

Investigate the control flow narrowing logic in the TypeScript compiler, specifically in checker.ts. Compare how truthy checks (if (res.success)) are handled versus explicit boolean comparisons (if (res.success === true)). The bug suggests that with strictNullChecks off, truthy checks fail to narrow union types correctly. Look for the narrowing function for boolean discriminants and see why it misses the case where a property is compared to true/false vs. a truthy check. Also consider the effect of strictNullChecks on the narrowing algorithm.