rescript-vitest v1 didn’t work well with uncurried mode, and I think it has few users.
It now works with all compilers since v10, regardless of whether it’s in uncurried mode or not.
Take a look and let me know what you think.
10 Likes
Thank you for this new version! 
At work, we’ve developed our own bindings, which are heavily inspired by your rescript-vitest.
In my team, some developers come from a TypeScript background and are used to the robust Jest/Vitest integration enabled by source maps. Naturally, they feel the lack of proper testing integration in the Rescript ecosystem.
It seems like source maps support in Rescript isn’t on the roadmap for now. While your bindings are brilliant and help a lot, do you also face challenges with this limitation when using Vitest?
If you expect seamless integration with tools like Vitest explorer, sourcemap alone doesn’t help, it needs syntax analyzation from a dedicated extension, which is pretty overkill to me.
And personally, I don’t use a debugger and am used to reading the output as is, so it’s not a high priority to me. But I think ReScript will definitely support it at some point, it’s just not an easy task to get right next version.
1 Like
Thank you for your reply 
I feel that the Vitest Explorer, while powerful, is an extra step that isn’t strictly necessary for most of our workflows. It’s a nice-to-have but doesn’t really address the core issues around testing integration with ReScript.
I’m thinking more of this kind of output which is linked to the transpiled js file and not the rescript file :
To work around the lack of proper source maps, we’ve ended up writing a separate test("", …) for every expect(…). While this approach isn’t ideal, it helps us identify failing assertions without relying too much on precise stack traces. (the move to rescript@v11/v12 should also help).
That said, this can make tests a bit more verbose, and some team members find it tedious compared to the streamlined experience they’re used to with Jest/Vitest in TypeScript.
Managing source maps in Rescript is undoubtedly very challenging. I understand that it’s a lot of effort for the community to handle.
Yes, it’s more difficult than having our own extension.
I’ve looked into Vitest a bit more, but even if we support sourcemap, there’s no guarantee that it will be reflected in the Vitest report automatically.
However, it’s possible that it could support source reporting with additional integration. I’ll look into it further, but it shouldn’t be difficult to implement IMHO.
3 Likes