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?
1 Like
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.
2 Likes
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?
1 Like
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.
8 Likes
Source maps are useful beyond debugging. I lean on code coverage a lot when writing tests. In particular I use Wallaby. I asked the Wallaby devs if they’d consider supporting various compile-to-JS languages like ReScript and PureScript and they said it should “just work” as long as those languages support source maps. Not supporting source maps means that ReScript won’t work with certain parts of the JS ecosystem.
I use Wallaby with ReScript without a problem. It just runs on the generated js code.
@DZakh do the coverage indicators show up in your ReScript source files? I couldn’t get this to work when I tried this (which admittedly was quite a while ago).
If you’re talking about this one, then no. It’s only shown when you open the generated file. And it actually makes complete sense to me. Because sometimes one branch of rescript might compile to two branches of js, we can’t map the coverage one to one.
And for coverage control I use Codecov during the CI step.
I’d expect it show lines like that as being partially covered if not all of the JS branches for a given ReScript line are covered. Not knowing which lines are covered makes Wallaby much less useful.
I mostly use it as a test runner, so I always know that all tests pass. And when something goes wrong, I use it to debug the generated JS code. The stories feature works great for this. When it comes to working with coverage, I check what lines aren’t covered in the generated code and match it to the ReScript source code by myself.
FWIW, there’s an OCaml library for working with sourcemaps that could be useful in adding support: https://github.com/flow/ocaml-sourcemaps.