Narrow generic conditional and indexed access return types when checking return statements #56941

gabritto · 2024-01-03T20:10:47Z

Motivation

Sometimes we want to write functions whose return type is picked between different options, depending on the type of a parameter. For instance:

declare const record: Record<string, string>;
declare const array: string[];

function getObject(group) {
    if (group === undefined) {
        return record;
    }
    return array;
}

const arrayResult = getObject("group");
const recordResult = getObject(undefined);

If we want to precisely express this dependency between the return type and the type of nameOrId, we have a few options.
The first one is to use overloads:

declare const record: Record<string, string[]>;
declare const array: string[];

function getObject(group: undefined): Record<string, string[]>;
function getObject(group: string): string[];
function getObject(group: string | undefined): string[] | Record<string, string[]>;
function getObject(group: string | undefined): string[] | Record<string, string[]> {
    if (group === undefined) {
        return record;
    }
    return array;
}

const arrayResult = getObject("group");
const recordResult = getObject(undefined);

However, if you make a mistake in the implementation of the function and return the wrong type, TypeScript will not warn you. For instance, if instead you implement the function like this:

declare const record: Record<string, string[]>;
declare const array: string[];

function getObject(group: undefined): Record<string, string[]>;
function getObject(group: string): string[];
function getObject(group: string | undefined): string[] | Record<string, string[]>;
function getObject(group: string | undefined): string[] | Record<string, string[]> {
    if (!group) { // An empty string is falsy
        return record;
    }
    return array;
}

const badResult = getObject(""); // Type says this returns `string[]`, but actually it returns a record.

then your function implementation doesn't respect the overload signatures, but TypeScript will not error.

The alternative to overloads is to use conditional types, like so:

declare const record: Record<string, string[]>;
declare const array: string[];

function getObject<T extends string | undefined>(group: T):
    T extends string ? string[] : T extends undefined ? Record<string, string[]> : never {
    if (group === undefined) {
        return record; // Error! Type 'Record<string, string[]>' is not assignable to type 'T extends string ? string[] : T extends undefined ? Record<string, string[]> : never'.
    }
    return array; // Error! Type 'string[]' is not assignable to type 'T extends string ? string[] : T extends undefined ? Record<string, string[]> : never'
}

const arrayResult = getObject("group");
const recordResult = getObject(undefined);

However, while everything works out for the callers of getObject, in the implementation TypeScript errors on the return statements, because it compares the type of the return expression to the annotated conditional return type, and Record<string, string[]> is not assignable to T extends undefined ? Record<string, string[]> : never.

Solution: conditional return type narrowing

For this PR, I propose a way of checking return statements that understands cases like above.
The idea is that, for the function above:

function getObject<T extends string | undefined>(group: T):
    T extends string ? string[] : T extends undefined ? Record<string, string[]> : never {
    if (group === undefined) {
        return record;
    }
    return array;
}

when checking the return statement return record, TS will know that group has type undefined. TS will also know that type parameter T corresponds exactly to the type of group. Combining those two pieces of information, TS will know that, inside that branch, the expected return type has to be Record<string, string[]> (or a supertype). Then, instead of checking return record's type against T extends string ? string[] : T extends undefined ? Record<string, string[]> : never, it will check return record's type against the Record<string, string[]> branch of the conditional, i.e. a narrowed version of the conditional type. Then there will be no error on the return statement. In the same manner, when checking the return statement return array, TS will know that group has type string, and that therefore it can check the type of the return statement against the string[] branch of the conditional return type.

For now, we can think of it like this: when we check return statement return record, we see that group has narrowed type undefined. Then, we plug that information back into the return type by instantiating T extends string ? string[] : T extends undefined ? Record<string, string[]> : never with T replaced by undefined.

Restrictions

Conditional types

Reasoning about conditional types is pretty tricky. In general, given a function f(...args): SomeConditionalType whose return type is some (generic) conditional type, we are not able to do the special check proposed above, because it wouldn't be safe.
We need to place some restrictions on what the conditional return type looks like in order for TS to safely analyze it.

We can safely analyze a conditional return type that has the shape T extends A ? AType : T extends B ? BType : never.
This means the conditional type needs to be distributive (i.e. its check type is a naked type parameter T) and have never as its false-most type, and it cannot have infer type parameters (e.g. it cannot be T extends [infer A] ? AType : T extends B ? BType : never).

Intuitively, we can think of this conditional type shape as reflecting the kind of code one would write in the implementation of such a function.

In addition to the previous restrictions, the type parameter constraint has to be a union type, and the extends types of the conditional (A and B above) have to be constituents of the type parameter's union constraint (T above), like so:

function fun<T extends A | B>(param: T): T extends A ? AType : T extends B ? BType : never {
    if (isA(param)) { ... }
    else { ... }
}

This is because, to narrow the return type, we first need to narrow the type of param (more on that below). When we narrow the type of param, in a lot of scenarios, we will start from its type, T, or in this case its type constraint, A | B. Then, we will further narrow that type based on information from control flow analysis, e.g. to pick either A or B (see getNarrowableTypeForReference in checker.ts).

Therefore, in this typical case, narrowing param means we will end up with a type that is either A, B, or a subtype of those. In turn, when we plug this narrowed type back into the conditional return type, this means we will be able to pick a branch of the conditional type and resolve it. e.g. if the narrowed type of param is A, the conditional type will resolve to AType.

These additional restrictions are a heuristic meant to capture the "happy path" of narrowing in TS. For instance, if the type parameter's constraint is not a union, then we might have a case like the below:

function bad<T extends unknown>(x: T): void {
  if (x != undefined) {
    const y: {} = x;
  }
  else {
    const y: null | undefined = x; // Error: `x` is not narrowed here
  }
}

function good<T extends {} | null | undefined>(x: T): void {
  if (x != undefined) {
    const y: {} = x;
  }
  else {
    const y: null | undefined = x; // Works: `x` is narrowed here
  }
}

(Note unknown is conceptually equivalent to {} | null | undefined, but writing Ts constraint as a union instead of unknown makes narrowing work.)

Aside: why `never`

A common way of trying to write a conditional return type is like the following:

function stringOrNumber<T extends string | number>(param: T): T extends string ? string : number {
  if (typeof param === "string") {
    return "some string";
  }
  return 123;
}

const num = stringOrNumber(123);
const str = stringOrNumber("string");
declare let strOrNum: string | number;
const both = stringOrNumber(strOrNum);

This example works fine and it would be safe for TS to allow that function implementation. However, in general, it is not safe to allow this pattern of conditional return type. Consider this case:

function aStringOrANumber<T extends { a: string } | { a: undefined }>(param: T): T extends { a: string } ? string : number {
  if (typeof param.a === "string") {
    return "some string";
  }
  return 123;
}

const aNum = aStringOrANumber({ a: undefined });
const aStr = aStringOrANumber({ a: "" });
// Bad! Type says `number`, but actually should say `string | number`
const aNotBoth = aStringOrANumber({ a: strOrUndef });

The problem boils down to the fact that, when a conditional return type resolves to its false branch, we can't know if the check type is related or not to the extends type. For the example above, when we plug in { a: undefined } for T in T extends { a: string } ? string : number, then we fall into the false branch of the conditional, which is desired because { a: undefined } does not overlap { a: string }. However, when we plug in { a: string | undefined } for T in T extends { a: string } ? string : number, we fall into the false branch of the conditional, but this is not desired because { a: string | undefined } overlaps { a: string }, and therefore the return type could actually be string.

Resolving a conditional type to its false-most branch of a conditional type doesn't provide TS with enough information to safely determine what the return type should be, and because of that, narrowing a conditional return type requires the false-most branch of the conditional to be never.

Type parameter references

As hinted at above, to narrow a conditional return type, we first need to narrow a parameter, and we need to know that the type of that parameter uniquely corresponds to a type parameter.
Revisiting our example:

function getObject<T extends string | undefined>(group: T):
    T extends string ? string[] : T extends undefined ? Record<string, string[]> : never {
    if (group === undefined) {
        return record;
    }
    return array;
}

To narrow the return type T extends string ? string[] : T extends undefined ? Record<string, string[]> : never, we first narrow the type of group inside the if branch, and then we can use that information to reason about what type T could be replaced with. This only works because the declared type of group is exactly T, and also because there are no other parameters that use type T. So in the following cases, TS would not be able to narrow the return type, because there is no unique parameter to which T is linked:

function badGetObject1<T extends string | undefined>(group: T, someOtherParam: T):
    T extends string ? string[] : T extends undefined ? Record<string, string[]> : never {
    ...
}

function badGetObject2<T extends string | undefined>(group: T, options: { a: number, b: T }):
    T extends string ? string[] : T extends undefined ? Record<string, string[]> : never {
    ...
}

Indexed access types

The reasoning explained above for conditional types applies in a similar manner to indexed access types that look like this:

interface F {
  "t": number,
  "f": boolean,
}

function depLikeFun<T extends "t" | "f">(str: T): F[T] {
  if (str === "t") {
    return 1;
  } else {
    return true;
  }
}

depLikeFun("t"); // has type number
depLikeFun("f"); // has type boolean

So cases like this, where the return type is an indexed access type with a type parameter index, are also supported by this PR. The thinking is similar: in the code above, when we are in the if (str === "t") { ... } branch, we know str has type "t", and we can plug that information back into the return type F[T] which resolves to type number, and similarly for the else branch.

Implementation

The implementation works roughly like this:
When checking a return statement expression:

We check if the type of the expression is assignable to the return type. If it is, good, nothing else needs to be done. This makes sure we don't introduce new errors to existing code.
If the type of the expression is not assignable to the return type, we might need to narrow the return type and check again. We proceed to attempt narrowing the return type.
We check if the return type has the right shape, i.e. it has a shape of either SomeType[T] or T extends A ? AType : T extends B ? BType : never, and what parameters the type parameters are uniquely linked to, among other requirements. If any of those requirements is not met, we don't continue with narrowing.
For every type parameter that is uniquely linked to a parameter, we obtain its narrowed type.
- Say we have type parameter T that is uniquely linked to parameter param. To narrow the return type, we first need to obtain the narrowed type for param at the return statement position. Because, in the source code, there might not be an occurrence of param at the return statement position, we create a synthetic reference to param at that position and obtain its narrowed type via regular control-flow analysis. We then obtain a narrowed type N for param. (If we don't, we'll just ignore that type parameter).
Once we have the narrowed type for each type parameter, we need to plug that information back into the return type. We do this by instantiating the return type with a substitution type. For instance, if the return type is T extends A ? AType : T extends B ? BType : never, T is linked to param, and param has narrowed type N, we will instantiate the return type with T replaced by T & N (as a substitution type).
Once we obtain this narrowed return type, we get the type of the return expression, this time contextually checked by the narrowed return type, and then check if this type is assignable to the narrowed return type.

Instantiation

As mentioned above, the process of narrowing a return type is implemented as instantiating that return type with the narrowed type parameters replaced by substitution types. Substitution types can be thought of as T & A, where T is the base type and A the constraint type. There are a few changes made to instantiation to make this work:

There is now a new kind of substitution type, indicated by the ObjectFlags.IsNarrowingType flag, which corresponds to substitution types created by return type narrowing.
These narrowing substitution types are handled in a special way by conditional type instantiation functions, i.e. getConditionalTypeInstantiation, and getConditionalType.
getConditionalTypeInstantiation is responsible for distributing a conditional type over its check type. When instantiating a distributive conditional type in getConditionalTypeInstantiation, if the conditional's check type is a substitution type like T & (A | B), the usual logic would not distribute over this type, because it's a substitution type and not a union type. So, for distribution to happen, we have to take apart the T & (A | B) into (T & A) | (T & B), and distribute over that.
The other special thing that we have to do in getConditionalTypeInstantiation is to take the intersection of the distribution result, as opposed to the union. This is because, if we narrow a type parameter T to A | B, and we have a conditional return type T extends A ? R1 : T extends B ? R2 : T extends C ? R3 : never, then we don't know which branch of the conditional return to pick, if branch T extends A ? R1, or branch T extends B ? R2, so we have to check whether the return expression's type is assignable to both, i.e. assignable to R1 & R2.
Validating whether the conditional type has the right shape to be narrowed happens on-demand in getConditionalTypeInstantiation (and also at first as an optimization in checkReturnExpression when we're deciding whether to narrow the return type). This is because, as we instantiate a type, we may produce new conditional types that we need to then decide are safe to narrow or not (see nested types case in dependentReturnType6.ts test).

Conditional expression checking

To support conditional expression checking in return statements, this PR changes how we check a conditional expression in a return statement. Before this PR, when checking a return statement return cond ? exp1 : exp2, we obtain the type of the whole expression cond ? exp1 : exp2, and then compare that type to the return type. With this PR, we now separately check each branch: we first obtain the type of exp1, and compare that type to the return type, then obtain the type of exp2 and compare that type to the return type. This allows us to properly check a conditional expression when return type narrowing is needed.

This a breaking change, and the only change that affects existing code, but this change finds bugs. Analysis of extended tests changes: #56941 (comment).
This change also slightly affects performance because we do more checks. Latest perf results here: #56941 (comment).

Performance results

This feature is opt-in. Currently, virtually no code has functions whose return types are conditional or indexed access types that satisfy the restrictions above, so no code goes down the new code path for narrowing return types. This means for existing code, there's no performance impact from the return type narrowing. The only current performance impact is from the conditional expression checking change (see a version of this PR without the change for conditional expressions: #60268 (comment)).

Assessing the performance of the new code path is tricky, as there are no baselines. The existing alternative to conditional return types is to use overloads. In one scenario I tested, checking a function written with conditional return types with this PR took ~+16% check time compared to the same function using overloads and the main branch. However, that's for checking the function declaration. In a different scenario where I included a lot of function calls though, the version with conditional return types + this PR took ~-15% compared to overloads + main branch. So I'd say the performance is acceptable, especially considering you get stronger checks when using conditional return types, and also only a small number of functions in a codebase should be written using this feature.

Unsupported things

Inference:
TS will not infer a conditional return type or an indexed access type for any function or expression. Inferring such a type is more complicated than checking, and inferring such a type could also be surprising for users. This is out of scope.
Contextually-typed anonymous functions:

type GetObjectCallback = <T extends string | undefined>(group: T) => T extends string ? string[] : T extends undefined ? Record<string, string[]> : never;

const getObjectBad1: GetObjectCallback =
    (group) => { return group === undefined ? record : array }; // Error

declare function outerFun(callback: GetObjectCallback);
outerFun((group) => { return group === undefined ? record : array }); // Error

This is because, if your function does not have an explicitly annotated return type, we will infer one from the returns.

Detection of link between parameter and type parameter in more complicated scenarios:

// All cases below are not recognized
// Type alias
type Id<X> = X;
function f2<T extends boolean>(arg: Id<T>): T extends true ? string : T extends false ? number : never {
  if (arg) {
    return "someString";
  }
  return 123;
}

// Property type
function f3<T extends boolean>(arg: { prop: T }): T extends true ? string : T extends false ? number : never {
  if (arg.prop) {
    return "someString";
  }
  return 123;
}

// Destructuring
function f4<T extends boolean>({ arg }: { arg: T }): T extends true ? string : T extends false ? number : never {
  if (arg.prop) {
    return "someString";
  }
  return 123;
}

// Combinations of the above, e.g.:
type Opts<X> = { prop: X };
function f5<T extends boolean>(arg: Opts<T>): T extends true ? string : T extends false ? number : never {
  if (arg.prop) {
    return "someString";
  }
  return 123;
}

This could be supported in the future.

…n statement

gabritto · 2024-01-03T20:11:06Z

@typescript-bot perf test this

typescript-bot · 2024-01-03T20:11:09Z

Heya @gabritto, I've started to run the regular perf test suite on this PR at a3a54ce. You can monitor the build here.

Update: The results are in!

gabritto · 2024-01-03T21:30:56Z

@typescript-bot perf test this

typescript-bot · 2024-01-03T21:30:58Z

Heya @gabritto, I've started to run the regular perf test suite on this PR at 1b7489f. You can monitor the build here.

Update: The results are in!

tests/cases/compiler/dependentReturnType7.ts

tests/cases/compiler/unusedLocalsInRecursiveReturn.ts

tests/baselines/reference/dependentReturnType1.errors.txt

sandersn · 2024-10-29T19:35:56Z

tests/baselines/reference/dependentReturnType2.errors.txt

+            if (!Meteor.settings) {
+                return undefined; // Error
+                ~~~~~~
+!!! error TS2322: Type 'undefined' is not assignable to type 'HelperCond<I, string, T | undefined, RegExp, SettingComposedValue<T>[]>'.


It's too bad we don't give any elaboration here.

Yes, I don't really know how we could provide more feedback when we can't narrow a return type. It's already not 100% clear whether the user is trying to narrow the return type or not, and even when we think they are, I can't think of a good mechanism to explain why we didn't narrow.

andrewbranch

Excellent write-up. I have a couple questions.

andrewbranch · 2024-10-30T16:08:08Z

src/compiler/checker.ts

@@ -19081,14 +19098,17 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
            if (checkType === wildcardType || extendsType === wildcardType) {
                return wildcardType;
            }
+            const effectiveCheckType = forNarrowing && isNarrowingSubstitutionType(checkType)


Why do you need both forNarrowing and to check the flags of the check type?

forNarrowing = true is passed by getConditionalTypeInstantiation when we validate the conditional type is safe to narrow. It could be that the check type is a narrowing substitution type, but we don't want to narrow the conditional type because it has an invalid shape.

I think I did this because it was inconvenient and a bit confusing for me to call the conditional type validation function from inside getConditionalType every time we loop to a new conditional type. I found it simpler to validate the whole conditional type in getConditionalTypeInstantiation and have getConditionalType loop on that type.

andrewbranch · 2024-10-30T16:21:35Z

src/compiler/checker.ts

+                            (t: Type) =>
+                                getConditionalType(
+                                    root,
+                                    prependTypeMapping(checkType, getSubstitutionType(narrowingBaseType, t, /*isNarrowed*/ true), newMapper),


I think the changes here aren't mentioned in your implementation notes. Why do we need custom logic for distribution when we're narrowing?

Good question.

We are using substitution types (which can be thought of as T & A, where T is the base type and A the constraint) to convey a type parameter's narrowing. When instantiating a distributive conditional type in getConditionalTypeInstantiation, if the conditional's check type is a substitution type like T & (A | B), the old logic would not distribute over this type, because it's a substitution type and not a union type. So, for distribution to happen, we have to take apart the T & (A | B) into (T & A) | (T & B), and distribute over that.

The other special thing that we have to do is to take the intersection of the distribution result, as opposed to the union. This is because, if we narrow a type parameter T to A | B, and we have a conditional return type T extends A ? R1 : T extends B ? R2 : T extends C ? R3 : never, then we don't know which branch of the conditional return to pick, if branch T extends A ? R1, or branch T extends B ? R2, so we have to check whether the return expression's type is assignable to both, i.e. assignable to R1 & R2.

A semi-related note is that validating whether the conditional type has the right shape to be narrowed happens on-demand (and also at first as an optimization in checkReturnExpression when we're deciding whether to narrow the return type). This is because, as we instantiate a type, we may produce new conditional types that we need to then decide are safe to narrow or not (see nested types case in dependentReturnType6.ts test).

There's a bunch of details I haven't included in the implementation notes because I don't have a full list of them 😅. I'll add those.

Would it make sense to always normalize union-containing substitution types into unions of substitution types before distributing?

I haven't thought about it, but I assume it would break something somewhere in weird ways.

something akin to that could help with some NoInfer problems: #60271 (comment) :p

I have this vague sense that it would be nice if the conditional-narrowing-specific logic didn’t affect the implementation of getConditionalTypeInstantiation, but even if it always normalized substitution types, I don’t have a suggestion for how to extract mapTypeToIntersection, so I guess it’s moot.

something akin to that could help with some NoInfer problems: #60271 (comment) :p

I think it's worth investigating what would happen if we normalize substitution types with union constraints like we do for intersections with unions, especially if it fixes some problems. But I'll leave that for the future.

weswigham

Just one question and one small suggestion - this looks good~

weswigham · 2024-10-30T21:12:36Z

src/compiler/checker.ts

+    // A narrowable conditional type is one that has the following shape:
+    // `T extends A ? TrueBranch<T> : FalseBranch<T>`, in other words:
+    // (0) The conditional type is distributive;
+    // (1) The conditional type has no `infer` type parameters;


Why's that? Is something like

function f<T extends [number, string] | [string, number]>(arg: T): T extends [number, infer U] ? U : never { if (typeof arg[0] === "number") { return arg[1]; } throw new Error("Got non numeric tuple"); }

for some reason not feasible to check? Is it just because we'd have to do inference between the true branch type and the candidate return type to fill in the infer type variable, and that's not implemented yet? Because I could equivalently write

function f<T extends [number, U] | [string, number], U extends string>(arg: T): T extends [number, U] ? U : never { if (typeof arg[0] === "number") { return arg[1]; } throw new Error("Got non numeric tuple"); }

which afaik is valid under these rules. I think all infer type parameters in types satisfying the rest of these rules can be rewritten like this pretty easily, which seems to imply the infer itself aughta work, but I could be wrong.

Basically I don't know how inference would work safely between the substitution type I'm using to represent a narrowed type parameter and the infer type parameters, given how inference works today.

In T extends [number, infer U] ? U : never, if we instantiate T with substitution type T & [number, string], we would infer from T & [number, string] to [number, infer U].
Now, we can't simply infer string for U, because it would not be sound to narrow the return type to string:
the caller can specify that T is [number, "foo"] and then U is inferred to be "foo", not string.
We'd have to infer something like T[1] & string or simply T[1] for U for this to be safe, and I think we don't have the ability to do that.

src/compiler/checker.ts

gabritto · 2024-10-31T17:54:30Z

@typescript-bot test it

typescript-bot · 2024-10-31T17:54:35Z

Starting jobs; this comment will be updated as builds start and complete.

Command	Status	Results
`test top400`	✅ Started	👀 Results
`user test this`	✅ Started	👀 Results
`run dt`	✅ Started	✅ Results
`perf test this faster`	✅ Started	👀 Results

typescript-bot · 2024-10-31T18:17:06Z

@gabritto Here are the results of running the user tests with tsc comparing main and refs/pull/56941/merge:

Something interesting changed - please have a look.

Details

adonis-framework

/mnt/ts_downloads/_/m/adonis-framework/tsconfig.json

[NEW] error TS2322: Type 'null' is not assignable to type 'string'.
- /mnt/ts_downloads/_/m/adonis-framework/node_modules/adonis-framework/src/Request/index.js(600,75)

puppeteer

packages/puppeteer-core/tsconfig.json

[NEW] error TS2322: Type 'BidiJSHandle<unknown> | BidiElementHandle<Node>' is not assignable to type 'Awaited<ReturnType<Func>> | HandleFor<Awaited<ReturnType<Func>>>'.
- packages/puppeteer-core/src/bidi/Realm.ts#L188 in packages/puppeteer-core/src/tsconfig.esm.json
- packages/puppeteer-core/src/bidi/Realm.ts#L188 in packages/puppeteer-core/src/tsconfig.cjs.json
[NEW] error TS2322: Type 'ElementHandle<Node> | JSHandle<unknown>' is not assignable to type 'Awaited<ReturnType<Func>> | HandleFor<Awaited<ReturnType<Func>>>'.

typescript-bot · 2024-10-31T18:17:55Z

Hey @gabritto, the results of running the DT tests are ready.

Everything looks the same!

You can check the log here.

typescript-bot · 2024-10-31T18:35:28Z

@gabritto
The results of the perf run you requested are in!

Here they are:

tsc

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Compiler-Unions - node (v18.15.0, x64)}
_Errors	₃₁	₃₄	_{🔻+3 (+ 9.68%)}	_~	_~	_{p=0.001 n=6}
_Symbols	_62,340	_62,363	_{+23 (+ 0.04%)}	_~	_~	_{p=0.001 n=6}
_Types	_50,379	_50,395	_{+16 (+ 0.03%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{192,901k (± 0.09%)}	_{195,406k (± 0.96%)}	_{+2,505k (+ 1.30%)}	_192,975k	_196,677k	_{p=0.031 n=6}
_{Parse Time}	_{1.31s (± 0.92%)}	_{1.31s (± 0.84%)}	_~	_1.29s	_1.32s	_{p=0.432 n=6}
_{Bind Time}	_0.72s	_0.72s	_~	_~	_~	_{p=1.000 n=6}
_{Check Time}	_{9.72s (± 0.56%)}	_{9.78s (± 0.30%)}	_~	_9.75s	_9.82s	_{p=0.087 n=6}
_{Emit Time}	_{2.71s (± 1.45%)}	_{2.74s (± 0.48%)}	_~	_2.72s	_2.76s	_{p=0.141 n=6}
_{Total Time}	_{14.47s (± 0.62%)}	_{14.55s (± 0.23%)}	_~	_14.52s	_14.60s	_{p=0.090 n=6}
_{angular-1 - node (v18.15.0, x64)}
_Errors	₃₃	₃₇	_{🔻+4 (+12.12%)}	_~	_~	_{p=0.001 n=6}
_Symbols	_947,886	_947,934	_{+48 (+ 0.01%)}	_~	_~	_{p=0.001 n=6}
_Types	_410,840	_410,955	_{+115 (+ 0.03%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{1,224,607k (± 0.00%)}	_{1,226,060k (± 0.00%)}	_{+1,453k (+ 0.12%)}	_1,226,012k	_1,226,117k	_{p=0.005 n=6}
_{Parse Time}	_{6.65s (± 0.85%)}	_{6.66s (± 0.71%)}	_~	_6.60s	_6.72s	_{p=0.809 n=6}
_{Bind Time}	_{1.88s (± 0.27%)}	_{1.89s (± 0.22%)}	_{+0.01s (+ 0.44%)}	_1.89s	_1.90s	_{p=0.022 n=6}
_{Check Time}	_{31.90s (± 0.60%)}	_{31.97s (± 0.36%)}	_~	_31.81s	_32.13s	_{p=0.471 n=6}
_{Emit Time}	_{15.24s (± 0.31%)}	_{15.18s (± 0.41%)}	_~	_15.07s	_15.25s	_{p=0.078 n=6}
_{Total Time}	_{55.68s (± 0.36%)}	_{55.69s (± 0.36%)}	_~	_55.45s	_55.90s	_{p=0.936 n=6}
_{mui-docs - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_2,495,026	_2,495,029	_{+3 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_Types	_908,645	_908,650	_{+5 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{2,307,202k (± 0.00%)}	_{2,313,900k (± 0.00%)}	_{+6,697k (+ 0.29%)}	_2,313,879k	_2,313,936k	_{p=0.005 n=6}
_{Parse Time}	_{9.33s (± 0.40%)}	_{9.33s (± 0.22%)}	_~	_9.29s	_9.35s	_{p=1.000 n=6}
_{Bind Time}	_{2.14s (± 0.19%)}	_{2.14s (± 0.35%)}	_~	_2.13s	_2.15s	_{p=1.000 n=6}
_{Check Time}	_{75.29s (± 0.51%)}	_{74.90s (± 0.36%)}	_~	_74.41s	_75.13s	_{p=0.173 n=6}
_{Emit Time}	_0.28s	_{0.29s (± 2.58%)}	_{🔻+0.01s (+ 4.17%)}	_0.28s	_0.30s	_{p=0.009 n=6}
_{Total Time}	_{87.04s (± 0.47%)}	_{86.66s (± 0.32%)}	_~	_86.16s	_86.92s	_{p=0.173 n=6}
_{self-build-src - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_1,258,087	_1,258,781	_{+694 (+ 0.06%)}	_~	_~	_{p=0.001 n=6}
_Types	_266,235	_266,471	_{+236 (+ 0.09%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{2,422,835k (± 0.01%)}	_{2,425,817k (± 0.01%)}	_{+2,983k (+ 0.12%)}	_2,425,688k	_2,426,174k	_{p=0.005 n=6}
_{Parse Time}	_{5.21s (± 1.05%)}	_{5.20s (± 0.53%)}	_~	_5.17s	_5.25s	_{p=0.748 n=6}
_{Bind Time}	_{1.92s (± 0.47%)}	_{1.95s (± 0.39%)}	_{+0.03s (+ 1.48%)}	_1.94s	_1.96s	_{p=0.004 n=6}
_{Check Time}	_{35.50s (± 0.35%)}	_{35.59s (± 0.16%)}	_~	_35.51s	_35.65s	_{p=0.298 n=6}
_{Emit Time}	_{3.04s (± 0.65%)}	_{3.02s (± 1.22%)}	_~	_2.96s	_3.06s	_{p=0.573 n=6}
_{Total Time}	_{45.69s (± 0.31%)}	_{45.74s (± 0.17%)}	_~	_45.65s	_45.84s	_{p=0.575 n=6}
_{self-build-src-public-api - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_1,258,087	_1,258,781	_{+694 (+ 0.06%)}	_~	_~	_{p=0.001 n=6}
_Types	_266,235	_266,471	_{+236 (+ 0.09%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{2,619,643k (±11.18%)}	_{2,622,085k (±11.19%)}	_{+2,442k (+ 0.09%)}	_2,500,959k	_3,221,358k	_{p=0.045 n=6}
_{Parse Time}	_{6.61s (± 2.23%)}	_{6.59s (± 1.84%)}	_~	_6.52s	_6.83s	_{p=0.376 n=6}
_{Bind Time}	_{2.16s (± 1.98%)}	_{2.20s (± 4.21%)}	_~	_2.10s	_2.37s	_{p=0.423 n=6}
_{Check Time}	_{43.37s (± 0.45%)}	_{43.39s (± 0.36%)}	_~	_43.24s	_43.67s	_{p=0.810 n=6}
_{Emit Time}	_{3.61s (± 3.02%)}	_{3.52s (± 3.65%)}	_~	_3.43s	_3.77s	_{p=0.149 n=6}
_{Total Time}	_{55.77s (± 0.61%)}	_{55.72s (± 0.47%)}	_~	_55.53s	_56.20s	_{p=0.936 n=6}
_{self-compiler - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_261,754	_262,180	_{+426 (+ 0.16%)}	_~	_~	_{p=0.001 n=6}
_Types	_106,477	_106,602	_{+125 (+ 0.12%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{438,797k (± 0.02%)}	_{439,725k (± 0.01%)}	_{+929k (+ 0.21%)}	_439,660k	_439,785k	_{p=0.005 n=6}
_{Parse Time}	_{3.53s (± 1.15%)}	_{3.54s (± 0.39%)}	_~	_3.52s	_3.56s	_{p=0.808 n=6}
_{Bind Time}	_{1.32s (± 0.48%)}	_{1.31s (± 0.79%)}	_{-0.01s (- 1.01%)}	_1.29s	_1.32s	_{p=0.028 n=6}
_{Check Time}	_{18.90s (± 0.40%)}	_{18.92s (± 0.17%)}	_~	_18.89s	_18.97s	_{p=1.000 n=6}
_{Emit Time}	_{1.54s (± 1.68%)}	_{1.51s (± 1.17%)}	_~	_1.49s	_1.54s	_{p=0.099 n=6}
_{Total Time}	_{25.29s (± 0.32%)}	_{25.27s (± 0.16%)}	_~	_25.23s	_25.34s	_{p=0.520 n=6}
_{ts-pre-modules - node (v18.15.0, x64)}
_Errors	₆₈	₇₀	_{+2 (+ 2.94%)}	_~	_~	_{p=0.001 n=6}
_Symbols	_225,919	_226,060	_{+141 (+ 0.06%)}	_~	_~	_{p=0.001 n=6}
_Types	_94,415	_94,488	_{+73 (+ 0.08%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{371,091k (± 0.01%)}	_{371,593k (± 0.01%)}	_{+502k (+ 0.14%)}	_371,534k	_371,643k	_{p=0.005 n=6}
_{Parse Time}	_{2.90s (± 0.42%)}	_{2.90s (± 1.39%)}	_~	_2.86s	_2.96s	_{p=0.560 n=6}
_{Bind Time}	_{1.58s (± 1.18%)}	_{1.57s (± 0.77%)}	_~	_1.56s	_1.59s	_{p=0.742 n=6}
_{Check Time}	_{16.36s (± 0.34%)}	_{16.48s (± 0.28%)}	_{+0.12s (+ 0.73%)}	_16.41s	_16.55s	_{p=0.008 n=6}
_{Emit Time}	_0.00s	_0.00s	_~	_~	_~	_{p=1.000 n=6}
_{Total Time}	_{20.83s (± 0.31%)}	_{20.95s (± 0.40%)}	_{+0.12s (+ 0.57%)}	_20.85s	_21.09s	_{p=0.020 n=6}
_{vscode - node (v18.15.0, x64)}
_Errors	₃	₁₀	_{🔻+7 (+233.33%)}	_~	_~	_{p=0.001 n=6}
_Symbols	_3,129,928	_3,138,510	_{+8,582 (+ 0.27%)}	_~	_~	_{p=0.001 n=6}
_Types	_1,078,947	_1,082,406	_{+3,459 (+ 0.32%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{3,219,514k (± 0.03%)}	_{3,228,901k (± 0.00%)}	_{+9,388k (+ 0.29%)}	_3,228,704k	_3,229,028k	_{p=0.005 n=6}
_{Parse Time}	_{14.07s (± 0.62%)}	_{14.04s (± 0.35%)}	_~	_13.95s	_14.09s	_{p=0.378 n=6}
_{Bind Time}	_{4.84s (±14.62%)}	_{4.57s (± 2.98%)}	_~	_4.47s	_4.78s	_{p=0.936 n=6}
_{Check Time}	_{86.30s (± 4.17%)}	_{85.18s (± 0.46%)}	_~	_84.77s	_85.73s	_{p=0.575 n=6}
_{Emit Time}	_{26.78s (± 2.23%)}	_{27.95s (± 2.06%)}	_{🔻+1.17s (+ 4.38%)}	_27.33s	_28.69s	_{p=0.005 n=6}
_{Total Time}	_{131.99s (± 2.65%)}	_{131.74s (± 0.58%)}	_~	_130.83s	_132.83s	_{p=0.471 n=6}
_{webpack - node (v18.15.0, x64)}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=6}
_Symbols	_287,028	_287,028	_~	_~	_~	_{p=1.000 n=6}
_Types	_116,316	_116,316	_~	_~	_~	_{p=1.000 n=6}
_{Memory used}	_{438,405k (± 0.02%)}	_{438,641k (± 0.02%)}	_{+236k (+ 0.05%)}	_438,550k	_438,767k	_{p=0.008 n=6}
_{Parse Time}	_{4.05s (± 0.88%)}	_{4.06s (± 0.96%)}	_~	_4.01s	_4.12s	_{p=1.000 n=6}
_{Bind Time}	_{1.73s (± 1.57%)}	_{1.75s (± 0.98%)}	_~	_1.73s	_1.78s	_{p=0.123 n=6}
_{Check Time}	_{18.54s (± 0.26%)}	_{18.51s (± 0.57%)}	_~	_18.41s	_18.66s	_{p=0.574 n=6}
_{Emit Time}	_0.00s	_0.00s	_~	_~	_~	_{p=1.000 n=6}
_{Total Time}	_{24.33s (± 0.36%)}	_{24.32s (± 0.45%)}	_~	_24.17s	_24.46s	_{p=0.936 n=6}
_{xstate-main - node (v18.15.0, x64)}
_Errors	₃	₄	_{🔻+1 (+33.33%)}	_~	_~	_{p=0.001 n=6}
_Symbols	_543,130	_543,130	_~	_~	_~	_{p=1.000 n=6}
_Types	_181,889	_181,891	_{+2 (+ 0.00%)}	_~	_~	_{p=0.001 n=6}
_{Memory used}	_{485,472k (± 0.02%)}	_{486,526k (± 0.01%)}	_{+1,054k (+ 0.22%)}	_486,450k	_486,656k	_{p=0.005 n=6}
_{Parse Time}	_{4.19s (± 0.38%)}	_{4.19s (± 0.54%)}	_~	_4.16s	_4.21s	_{p=0.807 n=6}
_{Bind Time}	_{1.46s (± 0.72%)}	_{1.47s (± 0.93%)}	_~	_1.45s	_1.49s	_{p=0.160 n=6}
_{Check Time}	_{23.82s (± 1.20%)}	_{23.83s (± 0.29%)}	_~	_23.77s	_23.95s	_{p=0.173 n=6}
_{Emit Time}	_0.00s	_0.00s	_~	_~	_~	_{p=1.000 n=6}
_{Total Time}	_{29.47s (± 1.03%)}	_{29.48s (± 0.27%)}	_~	_29.41s	_29.62s	_{p=0.228 n=6}

System info unknown

Hosts

node (v18.15.0, x64)

Scenarios

Compiler-Unions - node (v18.15.0, x64)
angular-1 - node (v18.15.0, x64)
mui-docs - node (v18.15.0, x64)
self-build-src - node (v18.15.0, x64)
self-build-src-public-api - node (v18.15.0, x64)
self-compiler - node (v18.15.0, x64)
ts-pre-modules - node (v18.15.0, x64)
vscode - node (v18.15.0, x64)
webpack - node (v18.15.0, x64)
xstate-main - node (v18.15.0, x64)

_Benchmark	_Name	_Iterations
_Current	_pr	₆
_Baseline	_baseline	₆

Developer Information:

Download Benchmarks

typescript-bot · 2024-10-31T19:40:42Z

@gabritto Here are the results of running the top 400 repos with tsc comparing main and refs/pull/56941/merge:

Something interesting changed - please have a look.

Details

alibaba/formily

29 of 38 projects failed to build with the old tsc and were ignored

packages/grid/tsconfig.json

error TS2322: Type 'T | T[]' is not assignable to type 'T'.
- packages/grid/src/index.ts#L111

packages/grid/tsconfig.build.json

error TS2322: Type 'T | T[]' is not assignable to type 'T'.
- packages/grid/src/index.ts#L111

antvis/G2

2 of 3 projects failed to build with the old tsc and were ignored

tsconfig.json

error TS2322: Type 'number[]' is not assignable to type 'Record<string, any>[]'.
- src/runtime/plot.ts#L1279

cheeriojs/cheerio

2 of 3 projects failed to build with the old tsc and were ignored

tsconfig.typedoc.json

error TS2322: Type 'boolean' is not assignable to type 'string | number | Document | Element | CDATA | Text | Comment | ProcessingInstruction | ChildNode[] | ... 6 more ... | undefined'.
- src/api/attributes.ts#L241

GrapesJS/grapesjs

1 of 3 projects failed to build with the old tsc and were ignored

packages/core/tsconfig.json

error TS2322: Type 'Component[]' is not assignable to type 'undefined extends T ? Components : Component[]'.
- packages/core/src/dom_components/model/Component.ts#L1019

honojs/hono

7 of 8 projects failed to build with the old tsc and were ignored

tsconfig.json

error TS2578: Unused '@ts-expect-error' directive.
- src/context.ts#L751
error TS2322: Type 'Response' is not assignable to type 'Response & TypedResponse<string, StatusCode, "text">'.
- src/context.ts#L753
- src/context.ts#L754

ionic-team/stencil

39 of 42 projects failed to build with the old tsc and were ignored

scripts/tsconfig.json

error TS2322: Type 'string | null' is not assignable to type 'string'.
- scripts/utils/release-utils.ts#L62

jupyterlab/jupyterlab

46 of 59 projects failed to build with the old tsc and were ignored

examples/filebrowser/src/tsconfig.json

error TS2307: Cannot find module '@jupyterlab/codemirror' or its corresponding type declarations.
- examples/filebrowser/src/index.ts#L25 in examples/filebrowser/src/tsconfig.json
error TS2307: Cannot find module '@jupyterlab/fileeditor' or its corresponding type declarations.
- examples/filebrowser/src/index.ts#L33 in examples/filebrowser/src/tsconfig.json
error TS7006: Parameter 'language' implicitly has an 'any' type.
- examples/filebrowser/src/index.ts#L99 in examples/filebrowser/src/tsconfig.json
- examples/filebrowser/src/index.ts#L102 in examples/filebrowser/src/tsconfig.json

examples/console/src/tsconfig.json

error TS2307: Cannot find module '@jupyterlab/codemirror' or its corresponding type declarations.
- examples/console/src/index.ts#L26 in examples/console/src/tsconfig.json
error TS2307: Cannot find module '@jupyterlab/console' or its corresponding type declarations.
- examples/console/src/index.ts#L28 in examples/console/src/tsconfig.json
error TS7006: Parameter 'theme' implicitly has an 'any' type.
- examples/console/src/index.ts#L96 in examples/console/src/tsconfig.json
error TS7006: Parameter 'extensionFactory' implicitly has an 'any' type.
- examples/console/src/index.ts#L102 in examples/console/src/tsconfig.json
error TS7006: Parameter 'options' implicitly has an 'any' type.
- examples/console/src/index.ts#L108 in examples/console/src/tsconfig.json
error TS7006: Parameter 'language' implicitly has an 'any' type.
- examples/console/src/index.ts#L123 in examples/console/src/tsconfig.json
- examples/console/src/index.ts#L126 in examples/console/src/tsconfig.json

microsoft/vscode

5 of 53 projects failed to build with the old tsc and were ignored

src/tsconfig.tsec.json

error TS2322: Type 'T | undefined' is not assignable to type 'T'.
- src/vs/platform/configuration/common/configuration.ts#L297
error TS2322: Type 'ContextKeyValue' is not assignable to type 'T | undefined'.
- src/vs/platform/contextkey/browser/contextKeyService.ts#L522
error TS2322: Type 'Result<TArgs>' is not assignable to type 'Result<GetLeadingNonServiceArgs<TArgs>>'.
error TS2322: Type 'null' is not assignable to type 'IStringDictionary<IFilterMetadata>'.
- src/vs/workbench/services/preferences/common/preferencesModels.ts#L108
error TS2322: Type 'undefined' is not assignable to type 'IExpression'.
- src/vs/workbench/services/search/common/queryBuilder.ts#L652

src/tsconfig.monaco.json

error TS2322: Type 'T | undefined' is not assignable to type 'T'.
- src/vs/platform/configuration/common/configuration.ts#L297
error TS2322: Type 'ContextKeyValue' is not assignable to type 'T | undefined'.
- src/vs/platform/contextkey/browser/contextKeyService.ts#L522
error TS2322: Type 'Result<TArgs>' is not assignable to type 'Result<GetLeadingNonServiceArgs<TArgs>>'.

nextauthjs/next-auth

22 of 44 projects failed to build with the old tsc and were ignored

packages/adapter-pg/tsconfig.json

error TS2322: Type 'null' is not assignable to type 'VerificationToken'.
- packages/adapter-pg/src/index.ts#L58

tailwindlabs/headlessui

2 of 5 projects failed to build with the old tsc and were ignored

packages/@headlessui-vue/tsconfig.json

error TS2322: Type 'TReturnValue | ((...args: any[]) => TReturnValue)' is not assignable to type 'TReturnValue'.
- packages/@headlessui-vue/src/utils/match.ts#L8

vuejs/devtools-v6

7 of 8 projects failed to build with the old tsc and were ignored

packages/api/tsconfig.json

error TS2578: Unused '@ts-expect-error' directive.
- packages/api/src/env.ts#L20
error TS2559: Type 'Window & typeof globalThis' has no properties in common with type 'GlobalTarget'.
- packages/api/src/env.ts#L22
error TS2559: Type 'typeof globalThis' has no properties in common with type 'GlobalTarget'.
- packages/api/src/env.ts#L24

vuejs/vue

7 of 8 projects failed to build with the old tsc and were ignored

tsconfig.json

error TS2578: Unused '@ts-expect-error' directive.
- src/platforms/web/runtime/directives/show.ts#L7
error TS2322: Type 'VNode | VNodeWithData' is not assignable to type 'VNodeWithData'.
- src/platforms/web/runtime/directives/show.ts#L10

gabritto added 22 commits May 15, 2023 18:15

WIP: custom instantiation

0d393e3

fix more things

a1d9f89

latest fixes

b9495a9

Merge branch 'main' into gabritto/d2

81cdee5

fix bare type parameter instantiation

af57b34

change binder. BROKEN

01152a0

fix binder change

eac3192

clean up + tests

199ecd0

WIP

d0e85d0

Merge branch 'main' into gabritto/d2

23e3d33

defer conditional unless narrowing

d9ac102

don't skip jsdoc type assertions

b4910f4

more fixes

6258bc0

WIP: account for pre-existing mapping

de3428d

only narrow when we take a true branch of a conditional

04980d3

small fix + new tests

e60a625

fix optional parameter handling and shadowing

ee2d1ba

fix skip parentheses

b8ce490

fix updates to binder, cleanup in checker

2439767

Merge branch 'main' into gabritto/d2

3f504f4

HasFlowNode update & fixes

5e8ca3e

cleanup; always check conditional expression's condition inside retur…

534cc38

…n statement

typescript-bot assigned gabritto Jan 3, 2024

typescript-bot added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Jan 3, 2024

This comment was marked as outdated.

Sign in to view

sandersn reviewed Oct 29, 2024

View reviewed changes

tests/cases/compiler/dependentReturnType7.ts Outdated Show resolved Hide resolved

sandersn reviewed Oct 29, 2024

View reviewed changes

tests/cases/compiler/unusedLocalsInRecursiveReturn.ts Show resolved Hide resolved

sandersn reviewed Oct 29, 2024

View reviewed changes

tests/baselines/reference/dependentReturnType1.errors.txt Show resolved Hide resolved

sandersn reviewed Oct 29, 2024

View reviewed changes

gabritto added 2 commits October 29, 2024 16:49

refactor tests

bd49834

refactor: feedback

03c9881

andrewbranch reviewed Oct 30, 2024

View reviewed changes

gabritto requested a review from sandersn October 30, 2024 18:40

sandersn approved these changes Oct 30, 2024

View reviewed changes

weswigham reviewed Oct 30, 2024

View reviewed changes

short circuit conditional type validation

26f2283

andrewbranch approved these changes Oct 31, 2024

View reviewed changes

use mapTypeToIntersection

86079ac

gabritto added this to the TypeScript 5.8.0 milestone Nov 1, 2024

gabritto merged commit 30979c2 into main Nov 6, 2024
32 checks passed

gabritto deleted the gabritto/d2-detect branch November 6, 2024 02:18

jcalz mentioned this pull request Nov 10, 2024

Discriminated Union Return Type #60467

Closed

andersk mentioned this pull request Nov 25, 2024

stream_events: Convert module to typescript. zulip/zulip#32454

Merged

Andarist mentioned this pull request Nov 30, 2024

Check if switch statements are exhaustive when their expressions is generic with a literal type constraint #60644

Merged

jfet97 mentioned this pull request Dec 2, 2024

Switch statements exhaustiveness check is failing when the expression has generic type but with literal type constraint #60658

Closed

jfet97 mentioned this pull request Dec 10, 2024

Let properties having primitive types discriminate object unions #60718

Open

gabritto mentioned this pull request Dec 18, 2024

Improve unknown narrowing by negated type predicates #60795

Merged

kirkwaiblinger mentioned this pull request Dec 19, 2024

Separately check ternary branches for assignability #60813

Closed

6 tasks

jcalz mentioned this pull request Dec 21, 2024

Property does not exist on selected type, but available via callback #60835

Closed

Narrow generic conditional and indexed access return types when checking return statements #56941

Narrow generic conditional and indexed access return types when checking return statements #56941

Conversation

gabritto commented Jan 3, 2024 • edited Loading

Motivation

Solution: conditional return type narrowing

Restrictions

Conditional types

Aside: why never

Type parameter references

Indexed access types

Implementation

Instantiation

Conditional expression checking

Performance results

Unsupported things

gabritto commented Jan 3, 2024

typescript-bot commented Jan 3, 2024 • edited Loading

This comment was marked as outdated.

gabritto commented Jan 3, 2024

typescript-bot commented Jan 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andrewbranch left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gabritto Oct 30, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Andarist Oct 30, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weswigham left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gabritto commented Oct 31, 2024

typescript-bot commented Oct 31, 2024 • edited Loading

typescript-bot commented Oct 31, 2024

/mnt/ts_downloads/_/m/adonis-framework/tsconfig.json

typescript-bot commented Oct 31, 2024

typescript-bot commented Oct 31, 2024

tsc

typescript-bot commented Oct 31, 2024

gabritto commented Jan 3, 2024 •

edited

Loading

Aside: why `never`

typescript-bot commented Jan 3, 2024 •

edited

Loading

typescript-bot commented Jan 3, 2024 •

edited

Loading

gabritto Oct 30, 2024 •

edited

Loading

Andarist Oct 30, 2024 •

edited

Loading

typescript-bot commented Oct 31, 2024 •

edited

Loading