Upgrading to latest rescript with ppx.deriving

1

I’m in the process of upgrading to the latest rescript (9.1.4). I made it safely up to 9.0.2 before I started running into some issues with [@@ppx_deriving. I wonder if I could get some direction on the best way to proceed.

From reading forum posts, it seems there is a move away from ppxes in rescript, and it also seems that the ppx_deriving/bs_deriving code has not been updated for the latest version of rescript. Also, the Format module, which the [@@ppx.deriving show] functions use, has been deprecated in rescript.

We’ve been using [@@ppx.deriving show] on all our types to create pretty printers, mostly for error handling. It generates functions like show_cursorState, which will turn cursorState into a string.

Is there something in Rescript that I can use to replace ppx.deriving, or some form of pretty-printing in rescript? If not, is there an idiomatic way to write custom preprocessors?

For reference, the error I get is:

Error: Cannot find module 'bs-platform/lib/bsc.exe' Require stack: - /home/dark/app/node_modules/ppx-deriving/identify.js - /home/dark/app/node_modules/ppx-deriving/ppx.js at Function.Module._resolveFilename (internal/modules/cjs/loader.js:962:15) at Function.resolve (internal/modules/cjs/helpers.js:78:19) at Object. (/home/dark/app/node_modules/ppx-deriving/identify.js:19:27) at Module._compile (internal/modules/cjs/loader.js:1118:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:1138:10) at Module.load (internal/modules/cjs/loader.js:982:32) at Function.Module._load (internal/modules/cjs/loader.js:875:14) at Module.require (internal/modules/cjs/loader.js:1022:19) at require (internal/modules/cjs/helpers.js:72:18) at Object. (/home/dark/app/node_modules/ppx-deriving/ppx.js:22:22) { code: 'MODULE_NOT_FOUND', requireStack: [ '/home/dark/app/node_modules/ppx-deriving/identify.js', '/home/dark/app/node_modules/ppx-deriving/ppx.js' ] }
2

on all our types to create pretty printers, mostly for error handling.

If it is mostly for error handling, recently we did lots of work to make the default Js.log output looks good, maybe you don’t need them

3

If it is mostly for error handling, recently we did lots of work to make the default Js.log output looks good, maybe you don’t need them

Well, I need them as strings as the errors don’t just go to console, they appear in the UI, get sent to rollbar, etc.

4

You can also use Js.Json.stringifyAny for error diagnostics

2 Likes
5

Thanks! I’ll try that.

6

Js.Json.stringifyAny isn’t really a good solution for this, as it gives output that looks like this:

{\"TAG\":1,\"_0\":{\"_0\":\"80997955\"},\"_1\":\"HTTP\"},{\"TAG\":1,\"_0\":{\"_0\":\"1753237011\"},\"_1\":\"/spec_name\"},{\"TAG\":1,\"_0\":{\"_0\":\"1235687565\"},\"_1\":\"POST\"}

while deriving.show used to give output like this:

(Filled("80997955", "HTTP"), Filled("1753237011", "/spec_name"), Filled("1235687565", "POST"))

It makes debugging extremely annoying and makes the output unsuitable for showing in a UI as well.

Is there a good alternative (or is one being worked on)? Thanks!

7

I can think of two options that might give you a better result from stringify:

  • decco (or atdgen) to encode a json object designed for external use
  • genType may produce translated variant names, I’m not sure, but that would mean compiling the typescript code as well
8

Are you aware that we have a debug mode “-bs-g” which gives you contructor name?

1 Like
9

Is there a way to use this to generate strings? (As opposed to the browser using it in devtools, which I’m assuming - perhaps incorrectly - is how this is intended to be used)