Using sourcemaps + exceptions tracing

Hey, so, how would one go around using sourcemaps?
I’m using Sentry(tried bugsnag before) to manage our exceptions. its an awesome product, but source-maps doesn’t seems to work. how do you guys manage exceptions in production?

Sourcemaps are not really on the radar: https://github.com/rescript-lang/rescript-compiler/issues/417

Here’s an issue with a little more discussion (there’s a mention of Sentry too), but it’s closed as well.

I wonder if it really as unnecessary as the ReScript team (and the Elm team) say it is. I tend to use breakpoints (and log points) a lot, but maybe I’m doing something wrong.

I like the idea of sourcemaps, and JS’s debugging infrastructure is amazing. But I assume it would mean a hit to compile times, and I think those are more important. Js.Console.log is great for debugging if they show up instantaneously.

BTW, you can skip the Console part and just write Js.log.

Also, I tend to set breakpoints in the .bs.js files, and the upside of that is that as a rule there are a lot of places to set breakpoints even when your ReScript code is pretty terse and point-free.

How do you guys deploy production systems like that?
you can’t do breakpoints on production(everything is minified,compacted,uglified etc). you can’t add console.log(well, you can, but wait 3m min for each deploy).

Source maps + Exception tracking is a MUST for any production system. not even sure what’s the reasoning of not having this… we’re at 2021, it’s just bizzare to give away such a powerful and common tool.

1 Like

I am not sure I am understanding this correctly.

  • So ReScript compiles to plain JS, that’s hopefully readable enough to figure out problems
  • You use webpack / some other tool to do the uglification process of the compiled JS sources
  • You’d probably need to enable source map generation with the same tool to map from uglified -> compiled JS source code, right?

Are you straight out taking the compiled ReScript code, uglify it and call it a day without any intermediate source maps to your compiled JS code?

unfortunately when dealing with Relude + Graphql + React its not easy at all going from js to reasonml(not even mentioning all the currying wrappers)

I am not sure about Relude, but not sure why debugging JS from graphql-ppx or reason-apollo-client should be hard (the JS generated is pretty clean).

1 Like

Graphql-ppx latest version is clean(we use the one before). its just more code someone needs to understand where it comes from. not that easy for everyone

We don’t use any third party service for exception tracking. But I recently thought about adding a small “comfort layer” to our exceptions using debugging functions in Pervasives (Debugging section, unfortunately this hasn’t been documented for rescript yet)
For example using __POS_OF__ when creating new exceptions. This way the compiler will insert the actual location in your rescript code and you don’t need to track your way through compiled js.

Of cause, this isn’t the same as source maps, but at least in our case this will add enough comfort.

I made a PR about the debugging values. Maybe you can suggest better examples as you may have more experience with them:

1 Like

Guys, i’m just adding to this discussion one small details:
Not all developers are super-amazing-ninjas who are happy to translate js to rescript and vice-versa - it’s not that easy.
some developers just want a simple: error happened in this line of the code.
Specifically, if they’re coming from Typescript and such, and they come to expect this experience.

Everything else here is just lying to ourselves that “this is good enough” or “this is not a problem”. It’s just sub-par and we should at least acknowledge that when prioritization decisions are being made regarding the roadmap.

5 Likes