For what it’s worth, on a personal note. I’ve recently spent some time trying to find solutions to the binding problem. I think it’s fair to say that out of the major outstanding ones, this is the perhaps the most challenging problem.
The exploration involved a number of ideas, some of those extreme: incorporate TypeScript as an embedded language so you can just “use it” and the binding problem per se disappears. (Replaced by a host of other problems and questions).
What was encouraging though, was an exploration: start by a compiler version with all the latest features, try to bind to some API see how it goes.
Personally, I did not encounter any problems at al. So that sounded encouraging as a first baby step.
I received at leas one report of someone else having the same experience.
It seems worth digging a bit more in that and see if those couple of cases do generalise more widely. But it’s very early days so we’ll see.
That sounds pretty interesting 
I think a solution like definitelytyped is a good stopgap for better solutions down the road. I don’t believe it requires unlimited resources, just community involvement.
For it to be successful it would require three things
- A repo to host all the bindings in, owned by the rescript org that automates the publishing of bindings to npm
- A small group of people that can casually look over prs that are submitted
- Have Rescripts compiler automatically find any installed bindings from the scoped package name we choose
After that it’ll grow organically over time. I think could work out well until better solutions are developed.
For what it’s worth i think @retyped/* is a good scope
That is not incompatible with more creative solutions, as long as it can be set up as some experiment that starts small and is reviewed along the way.
And of course it needs buy-in from the community.
There’s one dependency to take into account: the way bindings are written is under revisions. It seems one could have a much more intuitive way to write them without learning an entire dedicated dsl. While promising, this direction needs proper validation.
Once there is clarity of how bindings will look like, then one can consider next steps. Which can include a mixture of community involvement and automation.
As someone who provides various library bindings, I have a some of negative opinions about the way this works.
-
Unlike TypeScript/Flow, ReScript bindings have opinions. The reason is that ReScript bindings sometimes have runtime wrappers. Opinions on this obviously vary from project or user.
-
ReScript does not have declaration merging (for namespaces), so it is difficult to handle the shared types well. It cannot be 1:1 with JS packages.
-
DefinetelyTyped certainly has some successes, but it’s by no means perfect. It has various problems such as decentralized governance, compatibility, type inconsistency/inaccuracy, and high entry barriers.
The suggestion that will likely be tried next is: try to get to the desired outcome by putting as few resources as possible into this but do it differently and be creative.
There have certainly been several attempts like this in the BuckleScript days as far as I know. like importing types from DT, or typegen from TypeScript
If we make this, flow-typed is more acceptable than TS’s DefinetelyTyped IMO
It works as an independent tool instead of a project dependency (no deps-related problems), and because it replicates types to the project on install, it can be customized according to project-specific requirements.