Add the .getNonPrimitiveType() method to the TypeChecker

[mrazauskas]

Fixes #61517

This PR is adding the .getNonPrimitiveType() method to the TypeChecker. Similar to methods like .getAnyType() or .getUndefinedType(), the returned value of .getNonPrimitiveType() is the Type of the intrinsic object type.

A comment is included to explain what the method does. I think, it might not be clear that NonPrimitive is actually the intrinsic object type.

I updated the tests/baselines/reference/api/typescript.d.ts file. Is that enough for testing, perhaps? I looked around, but can’t find any explicit tests for other methods of the TypeChecker.

[typescript-bot]

The TypeScript team hasn't accepted the linked issue #61517. If you can get it accepted, this PR will have a better chance of being reviewed.

[typescript-bot]

Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page.

Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up.

[jakebailey]

What's the use for this one? I can understand the rest, but this seems like a weird one to need.

[ritschwumm]

is there any advantage in naming the method getNonPrimitiveType and comment that it actually returns the object type, instead of naming it getObjectType in the first place?

[mrazauskas]

What's the use for this one? I can understand the rest, but this seems like a weird one to need.

I was explaining my use case in the issue:

The project I am working on is using TypeScript programatically. The object type is used to validate user input. A user provides a type and the logic checks if that type is assignable to the object type. If not, a friendly message is printed that an object type was expected.

And here is the workaround I have at the moment (obviously, this cannot work with TypeScript 7 anymore):

const nonPrimitiveType = { flags: this.#compiler.TypeFlags.NonPrimitive } as ts.Type; // the intrinsic 'object' type

if (!typeChecker.isTypeAssignableTo(sourceType, nonPrimitiveType)) {
  // skipped
};

[mrazauskas]

is there any advantage in naming the method getNonPrimitiveType and comment that it actually returns the object type, instead of naming it getObjectType in the first place?

@ritschwumm See the issue, please. The naming was discussed there.

[mrazauskas]

this seems like a weird one to need.

@jakebailey I agree, it might seem so. In a way I could use overloads and the one which requires the input to be an object could have extends object constraint. But.. Adding // @ts-expect-error just a line above disables any constraints.

A user might add // @ts-expect-error for any reason or simply by make mistake. The project I talk about does not execute the code. It use TypeScript programmatically to analyse types. The programmatic usage helps to catch user mistakes.

For example, current I can easily validate that the provided type is a function (type.getCallSignatures().length !== 0), but there is no simple way to check, if that is an object or not. Although it seems like object is an intrinsic type just like string or null. Current APIs allow to get the null, but not the object type.

Please, take into account the type provided by a user can be a union or an intersection. Hence looking for the NonPrimitive type flag is some job. Doable, but why not to rely on already existing TypeScript’s logic:

if (!typeChecker.isTypeAssignableTo(sourceType, typeChecker.getNonPrimitiveType())) {
  // skipped
};