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.