Glutinum Type Provider for Fable imports across languages?

[jkone27]

suggestion/idea/dream : ) if this could help make it to a type provider for Fable imports?

a typescript definition type provider using glutinum in the background ,something like CSS type provider, but instead using glutinum in the background, to generate types for F# would be awesome

https://github.com/zanaptak/TypedCssClasses

open Fable.Imports.TypeProvider

// same as npm or bun i axios and get d.ts type from there and run it through glutinum and gen the types
// eventually could be expanded in the future for python and other languages in Fable??
// lang ts could be the default maybe
type Axios  = GlutinumProvider<"axios", Lang="ts"> 

let result = Axios.get("http://google.com")

[MangelMaxime]

Right now this is out of scope for Glutinum but could be revisited in the future depending on how feasible it is.

At the moment, I see several blocking or problematic points:

1. TypeProvider performance is often not that great. I used TP in the past and found that it was great for small script but for complex project it was not always the case. I remember the TypedCssClasses to be can of slow on complex CSS frameworks.

2. Glutinum needs to use the TypeScript compiler in order to access the TypeScript AST (we don't want to rewrite a TypeScript compiler). The typescript compiler is a Node.js program, I am unsure if this is possible to spawn external programs for TypeProvider or not.

3. If Glutinum is provided as TP, we needs its output to be really solid. Because people would not be able to fix small or not so small imperfection in the generated output.

Right now, my plan of development for Glutinum is:

1. Supports single files transformation (allows us to add new TS syntax support and build the foundation or out optimiser pass)
2. Work on single NPM packages at once (follows import statement local to that NPM package)
3. Improve DX by providing tooling
   • Provide a Web editor to see live the generated result (like ts2fable offers)
   • Provide a Web platform to search for NPM packages and generates the binding project out of it. The entry experience would be similar to what bundlephobia offers

4. Once we have good output from Glutinum, the plan is to allows Glutinum to generates bindings for all the packages installed locally (this would allows to detect some others optimisation that we can't do when doing a single package transformation). And with that the plan right now, is more leaning toward the way dts2hx handle it. Which is to generate the bindings projects on the fly locally and for people to consume them using a project reference.

   This is where we could potentially revisit using TypeProvider for Glutinum.

[goswinr]

Once Glutinum works well we could generate a fable nuget package for every package on https://www.npmjs.com/~types in an automated way. Or would that be a bad idea??

[MangelMaxime]

@goswinr It depends on how well Glutinum does but in reality I feels like the dts2hx approach would be better.

My reason for that is that, some of the optimisation will only be possible by having access to more than 1 package. The 2 main examples I have for that are:

• If an interface is defined in package A, and package use it as a react props we want to be able to detect that and switch output to Feliz output
• In a similar ways, if an interface is defined in package A, and a function of package B use this interface as an arguments we wants to switch the definition of the interface in package A into a ParamObject.

If we want this level of optimisation to be the default, then if we try to generates the bindings for every npmjs.com/~types it means having everything in memory 😅

Also, if we generate bindings based on what the user have installed on its machine. It means that the bindings will be generated for the exact version of the types installed in the user project.

If we generate bindings and publish them on NuGet, it means that there is always a change that they will be out of sync with the latest version possible or not matching the available API for the version installed in the user project.

We could probably just say that they will always be out of sync in reality ^^.