-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Type Builder API #9883
Comments
Just curious, could the API also provide a way to 'eval up' a type for simple cases, for brevity sake, e.g.: const c1 = builder.eval(`class { readonly x: number; readonly y: number; }`);
if (checker.isAssignableTo(c1, someOtherType)) {
// ...
} |
@yortus A eval like API is more approachable for new-comers. But for TypeScript compiler a low-level builder is more desirable. A low-level builder is more powerful for building complex types, e.g. conditional fields where arbitrary logic needs to be executed. And low-level builder does not mix parsing complexity in.
|
That's why I couldn't find |
Is this proposal dead? |
I'm releasing a simple version of this for checking types in runtime in |
Alongside the relationship API proposed in #9879, it would be very useful to expose an API to programatically build types - this is useful for making comparisons between a build-in type, and a type structure which isn't a part of the original compilation (lint rules, language service extensions, and external tools could find this a very useful API surface, and this is almost a prerequisite for a type provider-like feature). I have a protototype here, and the new API surface (excluding anything covered by #9879) looks like this:
which, in the end, looks like this when used:
The goal is to have a fluent API capable of creating an immutable version of any type or structure expressible within the type system. From my prototyping experience, there are only a handful of locations where a link or cache needed to be added to ensure the checker never needs to try to access an AST backing the types - so these "synthetic" or "declarationless" types actually tend to work fairly well within the checker once those are in-place. A few more links or hooks likely need to be added on top of those to ensure that the values are only retrieved lazily (rather than applied eagerly on API type creation). The laziness is actually super important for creating circularly referential types with an immutable API (otherwise a type can't really get a handle to it's finished self before it is done).
Known shortcoming: There's no method (in the type definition I have posted here) for making a member mapped to a well-known symbol, such as
Symbol.iterator
. I think this would just surface as parameters for object/class/interface members names takingstring | WellKnownSymbol
and having a method for looking up well-known symbols, though.cc: @ahejlsberg @mhegazy @DanielRosenwasser @rbuckton
I'd love to hear everyone's thoughts on this - the general fluent creation API I've been working off and on for the last few weeks, and I think it has real promise for letting consumers make valid types safely (and the intellisense support is top notch).
The text was updated successfully, but these errors were encountered: