Sourcemap support?

[jaredly]

I'd be interested in contributing sourcemap support, if you can give me some pointers in the right direction.

[bobzhang]

what do you think of working in this direction: https://github.com/bloomberg/bucklescript/issues/151

[jaredly]

That would also be a useful tool, but I think it's an entirely separate feature?

[jaredly]

I've used sourcemaps in clojurescript (which is quite a different language), and they're super useful

[lightsofapollo]

My 2c- when trying to convince my past teams and companies to use some X compile-to-js technology it was very, very difficult to win this argument without sourcemap support (particularly when doing some interop /w another JS only source)

[alcarvalho]

I had my boss demoing for me how clojurescript could be debugged from the browser, how you could use the REPL to connect to it and write clojurescript to inspect and change values on the fly.

IMHO having source maps is the very first step in the direction of having something that's easily hackable like clojurescript.

[v-ahuja]

We've started showing integrations of bucklescript in js stacks at Bloomberg and source-maps is a recurring question.

[bobzhang]

hi @vahuja13 , it is great to hear your progress, can you share with more a bit more about detail, or you can find me on discord and chat offline, thanks!

[dvisztempacct]

Any movement on this? @jaredly asked for some direction but I don't see any (at least in this thread.)

[hhugo]

You can have a look at the sourcemap implementation in js_of_ocaml here https://github.com/ocsigen/js_of_ocaml/blob/master/compiler/lib/source_map_yojson.ml.in

[aaronshaf]

Would be nice for test coverage

[dawee]

Would also be cool for tracking errors using sentry.

[texastoland]

Regardless whether it's useful for debugging, it's necessary for runtime tooling support like Quokka and blocking wallabyjs/quokka#153. @jaredly Did you already have a look how much work would be required? Has anyone attempted it?

[hoichi]

Chiming in to say that Wallaby.js introduced a Time Travel Debugger, so if we want to be on par with Elm*, we need source maps for the custom Wallaby compiler 😀.

Any news yet?

* I know it’s not the same time travel: in Elm’s case what changes through time is the state; in Wallaby’s, execution point.

[BlueHotDog]

Hi guys, any update on this? what are the blockers?

[Starcounter-Jack]

I love Bucklescript, but it is pretty much the only compiler/transpiler for Javascript that doesn't generate source maps. The alternatives such as Purescript, Typescript and Elm all do this for a good reason. It is not just for debugging. Scratchpads such as Quokka are really useful for functional languages. Code coverage tools such as Wallaby. Browsers let's you experience the language as a first class citizen. It really makes sense to tap in to the tooling ecosystem of Javascript in this way.

I appreciate that you have register line numbers from the original source file via the Ocaml/Reason AST, through to the internal representation and all the way to the code graph read by the Javascript code emitter and that there are two teams involved, but none the less, source maps is a must for a modern Javascript code emitter in 2020.

[seanpoulter]

How can we help? Should we crowdsource a design doc, help with the repo to free up some bandwidth, etc.? Let us know! 🤓

[hoichi]

The alternatives such as Purescript, Typescript and Elm all do this for a good reason

@Starcounter-Jack Sorry for the offtopic, but are you sure about Elm? I thought it was notorious for not even planning source maps.

[tienle]

I've just got this same question from one of my teammates when we were very first trying to investigate an exception from our Reasonml codebase. Anything that we can help to move this forward?!

[texastoland]

I assume someone just needs to implement it. My primary hesitation is doing a lot of work and not getting merged. It happened in a separate blocking issue. Any guidance from @bobzhang @chenglou or @jordwalke?

[chenglou]

Likely not gonna support it for a while. A bit too lossy of a technology.

[texastoland]

@chenglou Would you mind clarifying? Do you mean sourcemaps are lossy? Or that the work to implement them would be wasteful? The particularly compelling use case is integrating with other tools like Quokka.js and Wallaby.js: https://github.com/BuckleScript/bucklescript/issues/1699#issuecomment-493621031.

[chenglou]

Source maps are designed to be best-effort. Not to mention a pain to properly implement and maintain over years even under the best-effort design. There are emphasis and de-emphasis in a toolchain. Unfortunately in this case, our decision is to de-emphasize this particular feature. Particularly when our desire is for the toolchain to be robust and simple (well ok, several parts definitely aren’t so right now...)

[chenglou]

However I also don’t believe words alone convince many of folks wanting such feature. You can always experiment with source maps on your side and ship it independently, and monitor it over a few years to see the results (no snark implied in this at all btw. I think it’s a great way of learning things).

[texastoland]

This is the top most-upvoted issue of all time followed by #3276 which is the other one I'd be willing to spend my time on. It seems important for that reason alone. If you've ever used a tool like Quokka.js, Swift Playgrounds, or Scala Worksheets you'll understand why integration would be indispensable. Any architectural changes should be equally relevant to WebAssembly. PureScript was able to ship sourcemaps without a significant maintenance burden 4 years ago when I was heavily involved. In any case if the decision is it wouldn't be merged without years of testing the issue should be closed definitively.

[chenglou]

I happen to be rather familiar with Swift Playground, to say the least.

We'll always listen to feedback from user land, but that does not mean we'll always implement user land's suggested fixes. Regarding source maps, there are various complications regarding compilation and tooling glue that I kinda don't want to expand on here (but now that I did a little it looks like I'm making up excuses. Alas. Just trust that I have the right intent at least).

When Wasm becomes an important target, we can re-evaluate this. I don't really believe in prematurity supporting wasm due to various way, way trickier social and technical issues, too.

So yeah you're right... I'll close this for now. At least this doesn't keep folks' hope up with a vague answer. Sorry for dragging this on.

cc @jlongster. Not sure why but I thought you'd be interested in this discussion.

[Starcounter-Jack]

@hoichi You are right regarding Elm.

[Starcounter-Jack]

@chenglou As I am not contributing to the project, it would be presumptuous for me to complain. I'm sure you have good reasons.

[vasco3]

I wonder if we the new ReScript this feature request will be reconsidered.

[mweichert]

I think that would be a great addition as well.

On Thu, Oct 8, 2020 at 5:30 AM Jorge Cuadra notifications@github.com wrote:

I wonder if we the new ReScript this feature request will be reconsidered.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rescript-lang/rescript-compiler/issues/1699#issuecomment-705450032, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC3LC5HEXNHPVKEYCGFJRDSJWBCBANCNFSM4DOVT7QQ .

[kevinbarabash]

I spent some time about a year ago trying to improve the quality of PureScript's sourcemaps. I wanted to be able to use PureScript with Wallaby but the quality of the sourcemaps was so low that they were useable for that purpose. I don't think that "best effort" makes much sense when it comes to sourcemaps since if they're under a certain quality bar then essentially become useless.

Without knowing anything about the implementation of the ReScript compiler, it seems like one of the tricky aspects of getting sourcemaps to work with ReScript would be dealing with automatic uncurrying of functions. I'm sure there are other issues as well, possibly involving ppx.

I'm really excited for ReScript especially because of GenType. That being said, Wallaby is a huge part of my workflow, and it requires sourcemaps to work with compile-to-JS languages. I guess I'd have to actually build some stuff with ReScript to know if the tradeoff is worth it. 😅

You can always experiment with source maps on your side and ship it independently, and monitor it over a few years to see the results (no snark implied in this at all btw. I think it’s a great way of learning things).

Looking at the roadmap the only syntax change I see is the addition of docstring syntax in v10 (although past that the roadmap becomes more fuzzy). This seems like the most likely thing to impact keeping a fork with source maps up to date. Is there anything else a person taking this route should be wary of?

[listepo]

Maybe it's time to think about Sourcemap. We live in the 21st century, not the Middle Ages.

[sme-tuga001]

Pls add Sourcemap for 12 version cc @chenglou