Typedoc: Support for TypeScript 4.2.2

[doberkofler]

Search Terms

TypeScript 4.2.2

Problem

Unable to use TypeScript 4.2.2

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! Found: [email protected]
npm ERR! node_modules/typescript
npm ERR!   typescript@"4.2.2" from the root project
npm ERR!   peer typescript@"^3 || ^4" from @phenomnomnominal/[email protected]
npm ERR!   node_modules/@phenomnomnominal/tsquery
npm ERR!     @phenomnomnominal/tsquery@"4.1.1" from the root project
npm ERR!   3 more (ts-loader, tsutils, ts-jest)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer typescript@"3.9.x || 4.0.x || 4.1.x" from [email protected]
npm ERR! node_modules/typedoc
npm ERR!   typedoc@"0.20.28" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /Users/doberkofler/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/doberkofler/.npm/_logs/2021-02-23T23_20_54_048Z-debug.log

Suggested Solution

Support TypeScript 4.2.2

[Gerrit0]

npm actually errors on peer dependencies with unsupported versions now?! When did that happen?

I gave upgrading a shot, but it looks like 4.2 has caused some regressions that will take some more investigation to sort out... I should be able to put a release out this weekend at the latest.

[doberkofler]

Starting with version 7, npm has a more consistent handling of peer dependencies.

[Gerrit0]

Hmm.. well, this is problematic. TS 4.2 has said "TypeDoc's type conversion structure is inherently flawed"

TypeDoc's current structure assumes that converting a type to a type node to determine how to convert it is a reasonable approach - and it does work for a lot of cases!... but it doesn't work everywhere.

The test that's failing when updating to TS 4.2 is this one:

export class TestClass {
    a: string;
    b: number;
}

export class GenericClass<T extends keyof TestClass> {
    c: T;
}

Particularly, when converting the constraint of type parameter of the constructor member of GenericClass. This is because at that point, we are converting the type keyof TestClass, which is "a" | "b" - a union type. However, if we ask TS for a type node, it will give keyof TestClass - a type operator type.

The type converter then gets confused since it assumes that since TS gave us a type operator type node the type must be a type operator type, tries to access a property which doesn't exist, and converts the operated type to any, resulting in the signature:

new <T extends keyof any>() => GenericClass<T>

Properly fixing this is annoying, since it means ripping apart the type converter. I'm in the middle of moving this weekend, so I might not have time to finish it until next weekend.

[doberkofler]

Thank you for caring and good luck with the moving.

[Gerrit0]

Well, I'm nearly there. Turns out that with just a bit of poking at internals, I can make the existing converter keep working.
This led to finding one regression in TS - https://github.com/microsoft/TypeScript/issues/43072, but nothing that will prevent a release here.

CI is very unhappy with me since prettier doesn't support abstract signatures yet, but publishing manually did the trick.