rescript-stdlib-vendorer VS rescript-test

~/rescript-project-template/src/Demo.res:1 Found "Js" module usage. Use the vendored standard library instead. Read more at: https://github.com/DZakh/rescript-stdlib-vendorer

One problem is that it suggests creating A.res, which is publicly available from other application parts. It’s usually fine for FE apps, but for developing BE and CLIs, I prefer to follow the hexagonal architecture by creating the implementation inside the Main.res and passing it to other modules via function arguments. Once again, an example from rescript-stdlib-vendorer:

Besides bindings for JavaScript libraries, there is rescript-test - a lightweight test framework written in ReScript for ReScript. I have heard that some people like it, but for me, it lacks coverage output and Wallaby support.

As soon as you need to change the name or something, delete a field, or change a field… you’ve broken the API. This means you first need to change your Lambda(s) that use this new data, and ensure your unit tests (using ReTest) pass, and your integration tests (using Mocha & JavaScript) which invoke your Lambdas directly on a QA server still work.

To do that, we’re using rescript-test, which feels natural to those used to Jest, Mocha, etc. The only main difference is using testAsync vs test for async code, and having to define your own assertions vs. “Jest/Chai has ALL THE THINGS”.