Hello. I saw some indirect answers to this topic. However they are a bit dated and it is not easy to find them because they are kind of side answers to the main topic.
So the question is, are there any official nodejs bindings? If not, are they planned? And, if not, is there any good library already?
Thanks and regards
1 Like
Hi there!
AFAIK, no official bindings, nor official docs. But, take a look at rescript-compiler/jscomp/others at master · rescript-lang/rescript-compiler · GitHub, the node*.ml files. They define available bindings and available out of the box. They are in OCaml and so hard to read for a rescripter but it is better than nothing. I’m using them in production successfully.
for some official blessing of developers using ReScript for full-stack and not only React frontend.
2 Likes
Hi there! Thanks for pointing that out. I have no problem reading ocaml code, however I don’t see how can I use those bindings. Are you suggesting to copy paste them into my own project?
Seems that most of the work is already done, so I also wish for some official love for Node.js devs. I think BE developers are usually the more interested ones in type safety, so they are a great target
Here’s just an example of how I’m using these bindings without any extras:
let configAsInt = (key, default) =>
switch Node.Process.process["env"]->Js.Dict.get(key) {
| Some(s) =>
switch s->Int.fromString {
| Some(v) => v
| None =>
Js.Console.error(j`$key config value must be a valid integer. Got: $s`)
Node.Process.exit(1)
}
| None => default
}
I mean, you don’t have to copy anything. Just use the Node module which is available in the same way as Js or Belt.
Not official but this seems to be the most complete: GitHub - sikanhe/reason-nodejs: Node bindings for Reason and Bucklescript
EDIT: cross-posted in Discord
some random words here.
due semantical differences between js and rescript, and heavy usage of inheritance in js stdlib (DOM / Node APIs) everyone have a different taste about bindings to those apis (leve of abstraction/ amount of extra runtime code/ safety etc.) they can’t be modeled properly in rescript’s built in stdlib.
so what i would like to see is to include all (or most used / more general) types of js stdlib as abstract types in rescript’s standard library and people can come up with their desired bindings. this and libraries like the one Yawar mentiond for nodejs and bs-webapi would be best at current state.
2 Likes
Oh, awesome! Didn’t knew I can use those directly. This is exactly what I was looking for, thanks.
I do understand what @amiralies says, but I still se beneficial to have the majority of Node modules already binded, so you can use most of them and just build your own in case any of the existing ones doesn’t match your style.
It’s not the same as having to read the node api and then build your own (probably wrong at some details) bindings.
1 Like
Thanks for your answers both here and on Discord. I found those previously but this message:
Update (5/5/2020): Announcing the beta release of reason-node! You can find it on NPM here, and install it from your terminal using the installation instructions below.
Made me doubt if I should using them.
Also, because they are for reason I was not sure if I could use them with rescript and how.
I also think this is a good idea. I’m currently writing bindings for a library that produces a fs.Stats object, and I’m not sure how to define it. If there was an abstract type Node.Fs.stats I could define the value as such. This way my bindings would be able to work with some other bindings that may define methods for Node.Fs.stats.
It’s basically what we have with promises currently. There’s Js.Promise.t with not ideal bindings, but even the common type by itself is very helpful for communication between libraries.
reason-nodejs seems to have been abandoned not long after the ReScript rebranding, so late last year I forked it to create rescript-nodejs.
I don’t know if it helps, but here’s the fs.Stats binding.
6 Likes
Sorry, never answered. Those bindings look fantastic, thanks
1 Like