Repository navigation
Add .isApplicableIndexType() to the TypeChecker #61886
Description
Activity
I don't think we'll be further expanding the API surface since this is effectively a dead end with TS7 on the way. What's your use case for this?
The project I work on is using TypeScript’s programatic API. A user is providing a type and a key (string, number or symbol) and the logic checks whether the key exists in the type.
Without
.isApplicableIndexType()it is not possible to check index signatures with template literal string like:[key: `data-${string}`]. I mean, not possible to do that programatically. And it is not possible to reimplement.isApplicableIndexType()either because it uses private APIs, as mentioned above.
I do agree that expanding the API surface is not always acceptable.
As mentioned above, currently
.getStringIndexType()and.getNumberIndexType()are available onTypeobject. They do not cover index signatures with template literal string. In other words, these are outdated APIs and could be removed in favour of.isApplicableIndexType(). Not the best argument, but in a way the API surface becomes smaller.Reacted by Ryan CavanaughA user is providing a type and a key (string, number or symbol) and the logic checks whether the key exists in the type.
I understand the mechanical thing that's happening but I don't understand the motivation here.
Thanks for your time and also for your work on TypeScript. That’s a great value for many people. I appreciate that!
Meanwhile I came up with an alternative solution that works with older versions of TypeScript and does not require
.isApplicableIndexType()as well.
The use case is type testing.
(There are few libraries that try to implement type testing via generic type manipulation. I do not think that is good idea. Type manipulation is not the same as testing. What is testing? That’s a good question, indeed.)
The approach I am heading for: create a virtual file with erased syntax and type check it. I think that should work with any version of TypeScript.
Here is a concrete example:
import { expect } from "tstyche"; const sample: { [key: number]: unknown } = {}; expect(sample).type.toHaveProperty("123"); expect(sample).type.toHaveProperty(123); expect(sample).type.not.toHaveProperty("foo");
would be roughly turned into:
const sample: { [key: number]: unknown } = {}; (sample) ["123"]; (sample) [123]; (sample) ["foo"]; // error!
and all I have to do is to report or silence the errors.
By the way, I already implemented
.toBeCallableWith()in a similar way.- locked as resolved and limited conversation to collaborators
on Oct 22, 2025
🔍 Search Terms
"isApplicableIndexType", "TypeChecker"
✅ Viability Checklist
⭐ Suggestion
Please consider adding the
.isApplicableIndexType()method to theTypeChecker.📃 Motivating Example
Currently one can use
.getStringIndexType()and.getNumberIndexType()available on theTypeobject. Those work fine, but do not include symbol and template string pattern index signatures that were introduced in TypeScript 4.4.The change was made in #44512. The
isApplicableIndexType()function was added in the PR, but it is not public. Here is how it looks:Simple enough, but not possible to reimplement, because of a tiny detail:
numericStringType.💻 Use Cases
I pass
typeChecker.getIndexInfosOfType(sourceType)and want to check, if thetargetTypehas an applicable index signature:.getStringIndexType()and.getNumberIndexType()are available, but as mentioned above they do not cover all the cases..isApplicableIndexType()could cover these, but it is not public.Currently I am applying a patch that exposes
.isApplicableIndexType(). That cannot work in long term unfortunately.Also I have noticed that
.getStringIndexType()and.getNumberIndexType()do not exist anymore in TypeScript 7. Might be worth to remove or at least to deprecate them in Strada as well. An alternative? Obviously:.typeChecker.isApplicableIndexType().