Feature Request: F# style Type Provider support?

Could we get support for something like F#'s type providers in the future?

Let me present some use case scenarios for this… Let’s suppose you have a TS project trying to access a REST API, and this REST API uses Swagger or RAML for documentation. Well in this case we could have something like this;

var fooClient = new SwaggerClient<"http://foo.com/swagger.json">();
fooClient.getPeople((people) => {
    people.every((person) => console.log(person.firstName + "," + person.lastName);
});

and this could be completely type safe, as the SwaggerClient pulls down the API return types, method names (such as getPeople) and signatures at compile time and exposes them as methods to the type system. I think that’s pretty huge. Such clients could be written by the community for RAML, SOAP or what have you.

another nice one:

var doc = new Document<"index.html">()
doc.titleSpan.text = "Hello World!";
doc.myButton.addListener("clicked", () => { console.log("tapped!")});

In this example the Document type provider loads our index.html file and finds all the elements with id’s and figures out what types they are, and exposes them in the type system at compile time. Again, I think that’s pretty huge!

F# uses Type Providers for all kinds of things, so there’s lots of ways this can get used. It’s easy to see frameworks figuring out all kinds of amazing things that these could be used for. It also feels like a nice fit for TypeScript because it helps bridge the benefits on dynamic typing with the benefits of static typing.

one more tiny example:

console.log(StringC<"name:%s/tid:%n">("Battlebottle", 128));

a simple string formatter. This reads “name:%s/tid:%n” and knows that %s and %n must be replaced with a string and number respectively, so at compile time it produces a method that accepts a string parameter and a number parameter. Basically a statically typed string formatter. Just a tiny of example of handy little utilities that could be written with this feature. But the opportunity is pretty huge I think in general.

Any thoughts?

[leebyron]

I just wanted to voice my support and desire for this feature. I think it’s potentially incredibly valuable based on how TypeScript is often used these days for rich web apps with Webpack, REST & GraphQL, and other kinds of static but non-JS types.

@weswigham what ever came of your prototype from a couple years back? Did it at least yield a proposed API that could spark further discussion? I hope the TS team seriously considers building out this potential feature, though it could also be an excellent community contribution for a bold person given a clear proposed plan.

[weswigham]

So, speaking from experience, while technically you can make type providers work (and I have - I did have a functional prototype based on my extension model), a better solution (from a ux perspective) is triggered codegen. Rather than writing a library that generates the types from an API or some other file and injecting them directly into a compilation or language service, it’s a way better development experience to generate actual code from the API or file. When that’s done, you have a source file that actually exists and can be gone to with go-to-definition and inspected for deficiencies.

And I think a lot of people realize this (plus it already works today, since it doesn’t need any specific hooks) - that’s why there’s projects for generating type declarations for things like json schemas and swagger specs.