Fable: Use TypeProvider to automatically generate typings like FunScript did

Created on 23 Jul 2017  路  1Comment  路  Source: fable-compiler/Fable

Description

As .NET Core 2 is coming can TypeProvider be used to automatically generate typings?

Expected results

F# let `$` = DTS<jQuery.d.ts>

Most helpful comment

Yes, hopefully Type Providers are coming to .NETCore 2.0 (though I'm not 100% sure and there may also be limitations) and this will be a very good thing for Fable. However I don't think we'll be able to use a Type Provider to generate the bindings as there are many disadvantages. FunScript only use a TP in its early stage and when Typescript had many less features. To name a few hurdles:

  • TPs cannot generate generic types/methods.
  • When parsing the bindings, if there's an error users can easily fix it manually and contribute to the bindings (as it's already happening), with a TP you have to modify the code, make sure you're not breaking other bindings, publish a new packages, etc.
  • If the parser is a node app (as ts2fable is) you can use the TypeScript compiler API itself to parse TS files, this is much more difficult to with a Type Provider (I tried it in the past :wink:).
  • Parsed bindings can be versioned, so you can have reproducible builds even if the binding is updated with breaking changes.
  • Parsed bindings can easily be added to helpers, as in the Fable.React package.
  • etc.

With this, I just mean I'm not planning to work on a type provider for the bindings. But of course, I won't tie the hands of anyone who wants to give it a try ;)

>All comments

Yes, hopefully Type Providers are coming to .NETCore 2.0 (though I'm not 100% sure and there may also be limitations) and this will be a very good thing for Fable. However I don't think we'll be able to use a Type Provider to generate the bindings as there are many disadvantages. FunScript only use a TP in its early stage and when Typescript had many less features. To name a few hurdles:

  • TPs cannot generate generic types/methods.
  • When parsing the bindings, if there's an error users can easily fix it manually and contribute to the bindings (as it's already happening), with a TP you have to modify the code, make sure you're not breaking other bindings, publish a new packages, etc.
  • If the parser is a node app (as ts2fable is) you can use the TypeScript compiler API itself to parse TS files, this is much more difficult to with a Type Provider (I tried it in the past :wink:).
  • Parsed bindings can be versioned, so you can have reproducible builds even if the binding is updated with breaking changes.
  • Parsed bindings can easily be added to helpers, as in the Fable.React package.
  • etc.

With this, I just mean I'm not planning to work on a type provider for the bindings. But of course, I won't tie the hands of anyone who wants to give it a try ;)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MangelMaxime picture MangelMaxime  路  3Comments

krauthaufen picture krauthaufen  路  3Comments

tomcl picture tomcl  路  4Comments

rommsen picture rommsen  路  3Comments

MangelMaxime picture MangelMaxime  路  3Comments