typesafe-joi blows up TypeScript 3.2+

[hjkcai]

TypeScript Version: 3.3.0-dev.20181205

Search Terms:

Maximum call stack size exceeded

Code Repo:

https://github.com/hjkcai/typesafe-joi

Reproduction:

mkdir typesafe-joi-issue && cd typesafe-joi-issue
yarn add typescript@next @types/node typesafe-joi joi
echo '{"compilerOptions":{"strict":true}}' > tsconfig.json
echo 'import * as Joi from "typesafe-joi"; console.log(Joi)' > index.ts
npx tsc -p .

Expected behavior:

tsc should work.

I admit that typesafe-joi uses lots of type recursion, but it works fine in TypeScript 3.1. After upgrading to TypeScript 3.2, the error comes.

Actual behavior:

tsc itself encountered 'Maximum call stack size exceeded' (No stack trace printed)

[j-oliveras]

Without npx using command node_modules\.bin\tsc -p . I see the callstack:

RangeError: Maximum call stack size exceeded
    at resolveNameHelper (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:26036:35)
    at resolveName (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:26034:20)
    at resolveEntityName (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:26728:26)
    at resolveTypeReferenceName (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:31885:20)
    at getTypeFromTypeReference (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:32061:30)
    at getTypeFromTypeNode (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:33421:28)
    at getConstraintFromTypeParameter (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:31747:72)
    at fillMissingTypeArguments (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:31337:49)
    at getTypeFromClassOrInterfaceReference (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:31837:78)
    at getTypeReferenceTypeWorker (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:31950:24)

Running node setting a stack-trace-limit to 100000 (to see the full stack trace) with node --stack-trace-limit=100000 node_modules\typescript\bin\tsc -p .: full stack trace (is to large to paste here).

Seems that the recursion starts at call to getTypeFromTypeReference from checkTypeReferenceNode and the repetition is this callstack fragment:

    at getTypeFromTypeNode (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:33422:28)
    at getConstraintFromTypeParameter (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:31748:72)
    at fillMissingTypeArguments (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:31338:49)
    at getTypeFromClassOrInterfaceReference (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:31838:78)
    at getTypeReferenceTypeWorker (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:31951:24)
    at getTypeReferenceType (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:31893:24)
    at getTypeFromTypeReference (Z:\tmp\ts\node_modules\typescript\lib\tsc.js:32063:28)

[ahejlsberg]

The issue here is that AbstractSchema specifies itself as a constraint and relies on type argument defaults in that specification:

interface AbstractSchema<Schema extends AbstractSchema = any, Value = any> extends JoiObject { ... }

The use of default type arguments in combination with the recursive constraint causes an infinite loop. An easy fix for now is to specify the type arguments:

interface AbstractSchema<Schema extends AbstractSchema<any, any> = any, Value = any> extends JoiObject { ... }

[ahejlsberg]

@weswigham Best I can tell the infinite loop is caused by fillMissingTypeArguments attempting to get the constraint of the type parameter, which leads back to the same type, which leads back to needing to add default type arguments, and down the rabbit hole we go. I think you were last person to work on this so I'm assigning it over to you.

[hjkcai]

@ahejlsberg I assume TypeScript will fill in the type arguments automatically, because AbstractSchema have default type arguments. I will change my code later. Thanks a lot!

[EvgenyMuryshkin]

I made local fix, you can try to apply and see if it helps
EvgenyMuryshkin@9f88c2f

[ahejlsberg]

@EvgenyMuryshkin Doh! You're right, it definitely should be calling getConstraintOfTypeParameter (which checks for circularities) and not getConstraintFromTypeParameter (which is a worker function that doesn't). Thanks for catching this, I will turn it into a PR.