Rescript's own DefinitelyTyped

What are your thoughts around creating a repo like DefinitelyTyped that can publish bindings for popular libraries, with Rescript having governance over it?

In my opinion, something like @rs/jquery would make the Rescript a much more viable, and desired project to run with.

Look at this thread: ReScript real world expectations, libs and interop - #6 by ryyppy

PS: Are there really still jquery users? :laughing:

1 Like

Yeah, more than any other framework :woozy_face: .

I think some things should be taken pragmatically rather than idealistically. The average user wants something good enough rather than perfect. Rescript in general has moved towards a more pragmatic approach so to discount generalized bindings because of a puritan ideal seems inconsistent.

Ultimately, I think it would speed community adoption for people to be able to jump in and feel productive with an ecosystem that may not be ready for Rescript - much like Typescript’s early days was.

That whole thread linked by dkirchhof has lots of good info (and lots of links to other threads with good info), but just a recap…giant full-library bindings can be trouble.

It’s interesting you mention that, as imo, writing bindings only for the particular stuff you need seems like the most pragmatic thing to do, whereas constructing bindings for a large library that will have to be consistently maintained seems like the more idealistic view.

That being said, if there is a good way to have mostly automated way to manage big binding projects, then that is a different story.


Typescript has a great type ecosystem that is pragmatic in the sense that it only has to be done once, and by someone that isn’t necessarily you. How do you find having to write bindings for every single package you import pragmatic?

@types are curated by members of the typescript team, and other community efforts. There’s no automating it, but it’s worked out thus far.

Binding huge projects doesn’t seem to be a problem there. I think something that Rescript could benefit from is having a way to override bindings the way typescript can. That way if you have a certain need in a niche situation, you can always override whatever binding.

Mostly because I don’t write bindings for everything in every package, just a few functions from each library as I need them. So writing those bindings is quick. It’s rare that I need the full api surface of every library I’m using, so no need to write bindings for it, or depend on external bindings that aren’t maintained. There are just the bindings needed for the project, and maintained within the project. (Which also let’s me keep them as close to JS as needed, or as type safe as needed.)

As you say writing bindings for all of jquery every project is probably a bad idea, but that’s not what most of the bindings I’ve needed have been like. So of course, ymmv. And you could definitely be right and having a centralized thing could be good for Rescript.

Could be that part of the reason it works there is that the community is huge in comparison to Rescript. I can’t say for sure as I come from OCaml not JS ecosystem.

Edit: And of course, you will see a good number of bindings published by rescripters, and in theory I could see the benefit of a central place for them.


I do agree that for the most part, you don’t need to bind a whole project, but I think collectively, the community has probably wrote bindings for every major project out there. Like you said, centralizing and governing it with a curation for quality would make it nicer for the next person.

Planting DX trees is what, I think, makes a language prosper. The advancements Rescript has made recently will make it reach a tipping point, and making the onboarding process for new companies / devs to quickly get started will speed that up a lot

1 Like

DefinitelyTyped comes with a very big downside which is: you can (and more often than not will) end up with types that are not actively maintained nor accurate enough to be used into any reasonable production ready software.

It’s a really tedious process and ultimately makes you feel like “someone” didn’t do their job properly. I would rather have a set of very limited yet accurate bindings for the given task than having a whole library mapped approximately and around author inconsistencies. Just think about how JSON.stringify or parseInt are typed, make it exponential and you can easily see the flaws in definition files and, subsequently, in project like DefinitelyTyped.

Perhaps, the “average user” may not match with the “average ReScript user”. What makes ReScript interesting is how different and more robust its type system is: if I want something with a reasonable to high degree of uncertainty I would probably still with TypeScript or, even better, with vanilla JavaScript instead.


1 Like

I think to counter your points, you don’t have to use the types if they aren’t according to your needs.

That’s the point, if you want something good enough - then it’s available.

On your other point, Im not sure how easy it is to override bindings in Rescript are, but if work was done in that direction - it would make this all that simpler. If you’re not happy - override it

If the hypothesis is that it’d make it cheaper and easier to adopt ReScript, then I’d say it’s more a matter of someone leading the initiative than anything else (it’s easy to get stuck bike shedding).

I think it’s a good idea, even though I personally tend to create bindings to what I need (though certainly not always).

EDIT: I think a previously suggested name was “ReasonablyTyped”, which I personally find rather amusing

@cvr I would happily contribute what bindings I have to an @rs repo. While writing bindings is pretty easy, I have a large project with a growing bindings directory that is becoming an eyesore. Would much prefer if I could just reuse existing bindings and focus on my app

As @lessp says someone just needs to take the first step. It doesn’t need to be perfect project or famous at start, we can just start with contributing what we have in a community style until it eventually grows

What stops you from publishing bindings for a particular library in a separate package to gain some traction?

When I helped maintaining flow-typed, I realized how bad this concept of externally catered bindings in one place actually is. Maintainers not even using the JS libraries tried to put types on it, or merged PRs without knowing if the changes actually reflect reality. On the other hand some PRs were just stuck bc nobody knew if changes would break things. The actual JS libraries (even flow versions) were constant moving targets, so users were regularly stuck on particular library versions all the time or sacrificed sanity regarding misaligned types / runtime. Lots of complexity and OSS effort for not much gain. IMO the only major advantage of flow-typed was that the CLI vendored the bindings into your project, which allowed local modification if needed (defeating the point of having flow-typed as a single source of truth). ReScript’s binding repo would suffer the exact same issues (library version, ReScript version, binding version).

Additionally, ReScript bindings are not a 1-1 mapping thing either and you can’t write highly generic types, so you will eventually be torn apart by API discussions up to a point where ppl start to vendor / fork the definitions (without ever merging back to upstream).

I feel like this would actually cause newcomers to think that ReScript is just too complicated to work with, or they get discouraged to learn essential parts of the language. This idea (including generating bindings from d.ts files) has been popping up many times in the past few years, and whoever tackled it started to realize that it’s too much work and silently abandoned the project.

The community would benefit a lot by having more ReScript app show cases that map to common library scenarios, so ppl can just copy / paste them and adapt things until they work. Building a tool to make vendored binding files easier to manage for multiple projects would IMO also be useful.

I know this was probably not a serious name suggestion, but if this project ever should happen due to someone’s initiative, I’d politely ask to not call it “ReasonablyTyped”. We finally got to a point were we successfully detached from the Reason umbrella and I don’t want to explain again why Reason != ReScript :smile:. It’s a fun name, but I can already see that this will cause a lot of confusion.


What stops you from publishing bindings for a particular library in a separate package to gain some traction?

I think what I like most of the @types package is discoverability, there’s a ton of value in being able to do npm i @types/package -D for just about anything. With rescript there’s a little bit more of a barrier to finding what you need, where I’ll often opt for just writing my own bindings without searching google first. Then in a self fulfilling loop, I also don’t finish and publish my bindings, because I feel nobody would find them.

What about a central place to search for rescript packages? It doesn’t need to be complex, something like awesome rescript but for bindings. Could go into a json file and then deploy a simple UI search bar onto github pages

There is Package Index | ReScript Documentation


Wow this is sweet, I had no idea this existed

DefinitelyTyped has definitely been a major contributor to the success of Typescript. Copy pasting is not enough for he majority of people, and friction like that adds up to the detriment of Rescript’s adoption.

I think it’s wise to learn from the success of other languages, and incorporate it into ones own ecosystem. having an @rs package scope requires ownership from the rescript team - and it requires governance so that a reasonable standard(not perfect) of quality is placed.

The end result is that 80% of bindings are useful, and that goes a long way.

Something that Typescript is very good at is allowing overriding of bindings, so if we put effort in that regard - maybe this can end up being a great success.

Manually handling bindings is a thing of the past. As has been reported on this thread many times, it has been tried. That’s the first naive idea eveyone had like 3 years ago. It’s 3 years later and still it did not happen. A big complex conversion mechanism is also a thing of the past.
A little helper can write bindings for you, and we’ll explore this more next.


It requires buy in from the rescript team, as did Typescripts implementation. It has never happened because the rescript team does not want to do it for one reason to another.

That’s understandable, and fair. Though I would not say it is a faulty idea, since it’s Typescript is a huge example of it’s success

One small comment from me. When I see rs I think of rust not rescript.


That’s definitely a fair assumption: that putting unlimited resources in that one direction, it might work out.
I don’t think anyone said that they know exactly what would happen.
What I understand people say is: nontrivial resources have been put into this and it has not paid off.

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.