Description
They type checker has no public API for checking type relationships or for looking up types in a given scope. This can make writing semantic-analysis informed lint rules very difficult (either because you need to replicate a lot of logic, or because you simply don't have enough information). Since tslint enabled semantic checks we now have a popular consumer who would very much like to be able to perform meaningful semantic comparisons (See this rule for instance).
Proposal
A small new set of public API methods on the type checker:
interface TypeChecker {
isIdenticalTo(a: Type, b: Type): boolean; // Exposes internal identity relationship
isSubtypeOf(a: Type, b: Type): boolean; // Exposes internal structural subtype relationship
isAssignableTo(a: Type, b: Type): boolean; // Exposes internal assignable relationship
isComparableTo(a: Type, b: Type): boolean; // Exposes internal comparable relationship
isInstantiationOf(a: GenericType, b: GenericType): boolean; // While not an internal relationship, it is a straightforward semantic question to ask an answer which requires internal APIs to answer
lookupGlobalType(name: string): Type; // Looks up a global symbol named "name" with meaning SymbolFlags.Type (Identical to getGlobalType but without the expected arity based return value) - returns unknownType on failure
lookupTypeAt(name: string, position: Node): Type // Resolve a symbol lexically at the position specified with meaning SymbolFlags.Type (identical to resolveName, but with less levers) - returns unknownType on failure
getAnyType(): IntrinsicType;
getStringType(): IntrinsicType;
getNumberType(): IntrinsicType;
getBooleanType(): IntrinsicType;
getVoidType(): IntrinsicType;
getUndefinedType(): IntrinsicType;
getNullType(): IntrinsicType;
getESSymbolType(): IntrinsicType;
getNeverType(): IntrinsicType;
getUnknownType(): IntrinsicType;
getStringLiteralType(text: string): StringLiteralType; // When numeric literal types merge, they should have a similar endpoint
}
While this isn't a complete set of APIs for manipulating the type checker (I've left off an API to programatically create new types for comparison), it is enough to do meaningful analysis with existing types in the compilation without resorting to brittle (or often wrong) syntax-based solutions.