New here and probably asking an annoying question but is it possible to simply “use” the existing typescript ecosystem? Like can I simply import typescript as I can with js?
genType makes it smooth to import reason code into a typescript codebase. But I am trying to do (mainly) the opposite, which is import typescript modules into new reason ( and then compile it all to js ).
What am I missing?
2 Likes
It’s not generally possible. People have attempted it but could not make a general-purpose tool to do it.
Any opinion on this?
2 Likes
I think from the readme you can tell it’s an experimental project that will target TypeScript bindings in an opinionated, i.e. limited, way.
1 Like
There have been several discussions about TS -> ReScript type generation processes already, but it’s good you ask that question.
Even though it looks like an obvious thing to do, TS’ type system is still wildly different to ReScript’s, so there are many edge-cases that cannot be solved in a user friendly way, or are generally not worth solving.
Our goal with ReScript is to make it very very easy to write external bindings to JS apis on demand, so that users don’t get paralysed by choice doing type abstractions on complex APIs that are not easily generalizable (or not worth generalizing). Being able to quickly write a binding that reflects their concrete use-case within ReScript turned out to be the most pragmatic way getting things done and have simpler types that are easier to understand as well, either for their future selfs, or for their coworkers who need to read that code later on.
I know we advertise ReScript as a language that interacts nicely with existing codebases, but we’d still like to see less JS dependencies in ReScript codebases (but allow easy interaction if really needed). Many libraries that make sense in the JS ecosystem don’t necessarily make sense in the ReScript ecosystem, so giving ppl a half baked solution on generating (incomplete / wrong) type definitions is not really our goal.
In contrast, we polished the ReScript -> TS integration story (aka genType) because it’s technically way easier to convert from a strict type system to a gradual type system, and it also has a lot of benefits for our users that are gradually introducing independent ReScript modules in their existing codebases without compromising on the type experience when using imported ReScript modules in TS.
7 Likes
I’m a little confused by the responses here, unless I’m completely misunderstanding, it’s actually really easy to do what the OP is asking. I wrote about it here:
So now I’m wondering, what am I missing?!
2 Likes
How I understood the question: Is there a way to “just use a TypeScript value” without the extra work of typing an external.
Some ppl tried to fix it with codegen, which I already explained is unweildy.
In your approach, you are still required to write external bindings yourself, but you added some extra convenience that typescript will type check your code, I assume?
2 Likes
Ok yeah I see, thanks for the clarity. Yeah you have to write your own bindings, but genType generates code that TS uses to typecheck your bindings. For me that’s the best of both worlds – you get to define how you want your bindings to look, and genType then makes sure they’re compatible with the JS/TS package.
is this true even if using “strict” in TypeScript? could you ELI5 what are the issues why this is so hard, which Typescript concepts are hard to convert into ReScript? I’m really interested in ReScript, and I think taking advantage of people including .d.ts typings in their packages to achieve not ReScript-level, but at least TypeScript-level safety would be a necessary feature for wider adoption. Bit of a noob here, what am I missing?
TypeScript type system is unsound even in ‘strict’ mode, and there are various other issues that make their typings unreliable. I’ve covered some of that in this post: https://dev.to/yawaramin/typing-and-code-flow-in-typescript-and-reasonml-2paj
4 Likes