Add type relationship functions to checker public api - #9943

Anders Hejlsberg (@ahejlsberg) You probably want to weigh in on this.

I've added getter methods for numeric literals, true, and false. (Enum members should be lookup-able)

Could this be rebased and reviewed please?

I rebased this branch and all tests pass. You can access my changes at: Sheyne/TypeScript#1.
I didn't really do anything other than resolve a small merge conflict, but I can sign a CLA if need be.

+1 Daniel Rosenwasser (@DanielRosenwasser) can this one be revived?

This would be great, would love to see it make it in!

ping Daniel Rosenwasser (@DanielRosenwasser) this came up again

The thing I find hard to reason about is where to stop. Makes sense to expose the type relationship functions, resolveName (or some simplified version thereof), getTypeOfSymbol, and the built-in type accessor functions. But then what about getUnionType, getIntersectionType, getIndexType, getIndexedAccessType, createTypeReference, getTypeAliasInstantiation, createAnonymousType, createSymbol, etc. Without some of those, the utility of the type relationship functions seems limited as you can only use them if both types you want to compare actually exist in the program. For example, you couldn't compare to string[] because you have no way of manufacturing that type.

Just trying to understand what the guiding principle is here?

I (way back when this PR was first made) had a separate PR exposing safe APIs to programmatically build types (since the way we build types internally is very lazy and requires an associated node tree, etc) separate from this one. That's the main distinction here - this PR is for comparing and accessing existing types, while I have other work for public APIs for building types. However many things could operate only using existing types (like many lint rules), so the two need not be coupled (this is both easier to expose directly and arguably more immediately useful).

We should also add the factories that are needed, e.g. union, intersection, type reference instantiation, anonymous types, createSymbol. createSignature. and have a full proposal for the change.

Any update on this?

Kevin Buhmann (formerly Phelps) (@kevinphelps) The added wish of

We should also add the factories that are needed, e.g. union, intersection, type reference instantiation, anonymous types, createSymbol. createSignature. and have a full proposal for the change.

Is rather complicated, since what we use internally is super easy to misuse, and I, at least, would rather not directly expose those bits as is (esp. given how often we breakingly change them). A comprehensive proposal for a stable public view on type creation/comparison is big. A long time ago I started drafting an API here, but it's hopelessly outmoded now (even moreso than this PR), and I'm not even sure a fluent API is correct. 🙁
It's just a lot of work to put this together in a way we can maintain and other things are higher priority right now.

Thanks for your contribution. This PR has not been updated in a while and cannot be automatically merged at the time being. For housekeeping purposes we are closing stale PRs. If you'd still like to continue working on this PR, please leave a message and one of the maintainers can reopen it.

Why didn't we actually go for type relationship APIs in the first place and add the factories later? People (like me) have to use a 3rd party library (like ts-simple-type) which works, but has it's flaws. While the only thing I need (in my use-case) is isTypeAssignableTo so I can leverage the power of TypeScript itself while other libraries have a hard time figuring out assignability between types.

I understand that ideally in the end, everything like the factories is exposed as well. But to be honest, if the type relationship API, which Wesley Wigham (@weswigham) did in this PR, was exposed, it would make things much easier for people working with the TypeScript type checker directly.

If you can tell us a little bit about the use cases, that would be one step in the right direction. We assumed that the relationship APIs alone wouldn't be enough to solve most use cases.

I still am a bit skeptical given that there's other information I've heard people asking for (e.g. tracking the declared type vs. the flow-analyzed type at read positions) which requires more information to be exposed than originally expected.

Sure.

So I'm working on tsd which helps in testing type definitions written by hand. Sindre Sorhus (@sindresorhus) uses it in a ton of his packages already. It's a little like dtslint except that it doesn't use tslint (which is EOL) but leverages the power of the TypeScript compiler.

One thing that I'm now solving is exact type assertions. This means that I want to check that the expected type is exactly the type returned and isn't too wide. For instance, expectType<string | number>(['foo', 'bar'].join(', ')); currently works because string is assignable to string | number. But we want this to fail.

How do I check this? I use the AST to extract the type information of the generic and of the argument. If the argument type (string) is assignable to the expected type (string | number), but the expected type is not assignable to the argument type, the type is too wide.

So I looked into ts-simple-type to test assignability. It works in most use cases, but not for everything. For example, it has a big where it can't detect the assignability between generic types, e.g. it returns true for Observable<string | number> ~ Observable<string>.

I added one line to the type checker which exposed the isAssignableTo method, it then everything works as expected because TypeScript knows all this information and is much better in inferring these things.

So in my use case, only the assignability check would be necessary and would help me an awefull lot. Given the fact that there is a library like ts-simple-type which tries to mimick this, and is used by others, I think it would be very nice if TypeScript exposed this method (and maybe also the others in this PR, but that's not up to me to decide on how useful they are).

We assumed that the relationship APIs alone wouldn't be enough to solve most use cases.

I'm not sure what the original use cases are. But I think that for everyone working with the AST, based upon source files, will have all the types available and have enough with the relationships API.

I see them as separates scopes. The scope of this PR is "small" and easy to review. It offers functionality that I can use directly and helps me when working with the AST.

The factory methods on the other hand, as much as I understand them, allow you to create types dynamically and thus not based upon source files, or an already existing AST. This feels to me like a different scope and thus a different PR which can be specced out differently.

This is just my opinion though. You guys have much more knowledge and insights on use cases. I just think that it's a pitty that this PR became stall and people have to use 3rd party packages which try to mimick the TypeScript internals while the core already have all this information.

My use case in Sinap (https://github.com/2graphic/sinap-typescript-loader) was to use Typescript as a DSL for writing simple graph interpreters. The UI would allow you to build a graph (as in network, not as in plot) and the valid edges and nodes on the graph depended on the assignability of various types in .TS files in the interpreter.

I've not followed the factories described above, but if they don't allow easily checking assignability from types loaded from source files, then this is another example use case.

I also need isIdenticalTo in tsd. Because I really need these private API's, I copied over [email protected] entirely to a libraries directory which exposes isIdenticalTo and isAssignableTo (the latter will be available by casting somewhere in the next release probably). It was a decision I didn't want to make, but this was the only way I could leverage the power of the TypeScript APIs and build tsd with all the necessary power.