tsgo's IPC Checker exposes only a subset of tsc's public TypeChecker. PR #3403 is already extending it (getResolvedSignature, getTypeFromTypeNode, getNonNullableType, getWidenedType, getParameterType, isArrayLikeType, signatureToSignatureDeclaration). This issue surfaces another batch of public-API methods that aren't yet covered, with usage data from TSTL (a TS-to-Lua transpiler I use and have contributed to) to motivate prioritization.
Methodology
TSTL calls the checker directly rather than through the language service, so its surface is a reasonable lower bound for what a transpiler consumer needs.
Two cross-checking methods: a static sweep of TSTL src/, and runtime instrumentation of TSTL's getTypeChecker(). The sweep matches every \bchecker\.[a-zA-Z]+ call site and cross-references against tsgo's Checker class (_packages/native-preview/src/api/sync/api.ts) and TS's public TypeChecker interface (typescript.d.ts, TS 6.0.3). The instrumentation logs every checker call at runtime. Both methods identify the same first-order checker call set; the per-method call counts in the table below come from an instrumented transpile of a ~150-file TSTL project.
Results
Treat call counts as a rough priority signal, not a benchmark. They reflect what one ~150-file project happens to exercise; relative ordering between similar-magnitude methods may be an artifact rather than signal. Ordered by call count.
| Method |
Status |
Calls |
| getBaseConstraintOfType |
gap |
22,927 |
| Type.getProperty |
gap (instance) |
20,287 |
| isArrayType |
draft |
14,725 |
| isTupleType |
draft |
14,047 |
| getResolvedSignature |
#3403 |
8,372 |
| getConstantValue |
gap |
7,073 |
| Symbol.getJsDocTags |
gap (instance) |
3,978 |
| Symbol.getDocumentationComment |
gap (instance) |
3,397 |
| getSignatureFromDeclaration |
gap |
1,155 |
| getTypeFromTypeNode |
#3403 |
356 |
| getExportSpecifierLocalTargetSymbol |
gap |
122 |
| getContextualTypeForObjectLiteralElement |
TS internal |
71 |
| getNonNullableType |
#3403 |
39 |
| getElementTypeOfArrayType |
TS internal |
5 |
| getAliasedSymbol |
gap |
0 |
| getExportsOfModule |
gap |
0 |
(instance) in the Status column means the method lives on Type / Symbol instances rather than on Checker directly.
For Type.getProperty / checker.getPropertyOfType and getExportsOfModule / Symbol.getExports, either shape works from the consumer's standpoint — TSTL doesn't care which side the method lives on, so there's implementation flexibility on tsgo's end.
The two zero-count rows are reachable in src/ and exercised under tests; they just aren't triggered by this particular program.
On getResolvedSignature specifically: it's the one method here that's hard to reconstruct client-side. Reproducing it would need isTypeAssignableTo (public TS API, also missing) plus generic inference and contextual typing for arrow-function and object-literal args, which are TS internals and not a fit for IPC. That seems like the right primitive to expose server-side, which is the approach #3403 takes.
Ask
Per CONTRIBUTING.md I'll hold PRs until 7.0 ships, but flagging the gaps now.
The isArrayType/isTupleType draft linked in the table covers single-arg variants only (~350 lines, mirrors #3403's pattern). Held off on the array-overload variants to keep the diff small and leave that decision to maintainers; happy to add them if preferred.
tsgo's IPC
Checkerexposes only a subset oftsc's publicTypeChecker. PR #3403 is already extending it (getResolvedSignature,getTypeFromTypeNode,getNonNullableType,getWidenedType,getParameterType,isArrayLikeType,signatureToSignatureDeclaration). This issue surfaces another batch of public-API methods that aren't yet covered, with usage data from TSTL (a TS-to-Lua transpiler I use and have contributed to) to motivate prioritization.Methodology
TSTL calls the checker directly rather than through the language service, so its surface is a reasonable lower bound for what a transpiler consumer needs.
Two cross-checking methods: a static sweep of TSTL
src/, and runtime instrumentation of TSTL'sgetTypeChecker(). The sweep matches every\bchecker\.[a-zA-Z]+call site and cross-references against tsgo'sCheckerclass (_packages/native-preview/src/api/sync/api.ts) and TS's publicTypeCheckerinterface (typescript.d.ts, TS 6.0.3). The instrumentation logs every checker call at runtime. Both methods identify the same first-order checker call set; the per-method call counts in the table below come from an instrumented transpile of a ~150-file TSTL project.Results
Treat call counts as a rough priority signal, not a benchmark. They reflect what one ~150-file project happens to exercise; relative ordering between similar-magnitude methods may be an artifact rather than signal. Ordered by call count.
(instance)in the Status column means the method lives onType/Symbolinstances rather than onCheckerdirectly.For
Type.getProperty/checker.getPropertyOfTypeandgetExportsOfModule/Symbol.getExports, either shape works from the consumer's standpoint — TSTL doesn't care which side the method lives on, so there's implementation flexibility on tsgo's end.The two zero-count rows are reachable in
src/and exercised under tests; they just aren't triggered by this particular program.On
getResolvedSignaturespecifically: it's the one method here that's hard to reconstruct client-side. Reproducing it would needisTypeAssignableTo(public TS API, also missing) plus generic inference and contextual typing for arrow-function and object-literal args, which are TS internals and not a fit for IPC. That seems like the right primitive to expose server-side, which is the approach #3403 takes.Ask
Per CONTRIBUTING.md I'll hold PRs until 7.0 ships, but flagging the gaps now.
The
isArrayType/isTupleTypedraft linked in the table covers single-arg variants only (~350 lines, mirrors #3403's pattern). Held off on the array-overload variants to keep the diff small and leave that decision to maintainers; happy to add them if preferred.