Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sourcemap support? #1699

Closed
jaredly opened this issue Jun 9, 2017 · 30 comments
Closed

Sourcemap support? #1699

jaredly opened this issue Jun 9, 2017 · 30 comments

Comments

@jaredly
Copy link
Contributor

@jaredly jaredly commented Jun 9, 2017

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

@bobzhang
Copy link
Member

@bobzhang bobzhang commented Jun 12, 2017

what do you think of working in this direction: #151

Loading

@jaredly
Copy link
Contributor Author

@jaredly jaredly commented Jun 12, 2017

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

Loading

@jaredly
Copy link
Contributor Author

@jaredly jaredly commented Jun 14, 2017

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

Loading

@lightsofapollo
Copy link

@lightsofapollo lightsofapollo commented Jun 14, 2017

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)

Loading

@alcarvalho
Copy link
Contributor

@alcarvalho alcarvalho commented Jun 17, 2017

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.

Loading

@v-ahuja
Copy link
Contributor

@v-ahuja v-ahuja commented Aug 15, 2017

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

Loading

@bobzhang
Copy link
Member

@bobzhang bobzhang commented Aug 16, 2017

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!

Loading

@dvisztempacct
Copy link

@dvisztempacct dvisztempacct commented Jul 22, 2018

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

Loading

@hhugo
Copy link
Contributor

@hhugo hhugo commented Jul 22, 2018

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

Loading

@aaronshaf
Copy link

@aaronshaf aaronshaf commented Nov 30, 2018

Would be nice for test coverage

Loading

@dawee
Copy link

@dawee dawee commented Feb 19, 2019

Would also be cool for tracking errors using sentry.

Loading

@texastoland
Copy link

@texastoland texastoland commented May 17, 2019

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?

Loading

@hoichi
Copy link

@hoichi hoichi commented Dec 12, 2019

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.

Loading

@BlueHotDog
Copy link

@BlueHotDog BlueHotDog commented Apr 2, 2020

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

Loading

@Starcounter-Jack
Copy link

@Starcounter-Jack Starcounter-Jack commented Apr 10, 2020

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.

Loading

@seanpoulter
Copy link

@seanpoulter seanpoulter commented Apr 10, 2020

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

Loading

@hoichi
Copy link

@hoichi hoichi commented Apr 14, 2020

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.

Loading

@tienle
Copy link

@tienle tienle commented Apr 23, 2020

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?!

Loading

@texastoland
Copy link

@texastoland texastoland commented Apr 24, 2020

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?

Loading

@chenglou
Copy link
Member

@chenglou chenglou commented Apr 24, 2020

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

Loading

@texastoland
Copy link

@texastoland texastoland commented Apr 24, 2020

@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: #1699 (comment).

Loading

@chenglou
Copy link
Member

@chenglou chenglou commented Apr 24, 2020

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...)

Loading

@chenglou
Copy link
Member

@chenglou chenglou commented Apr 24, 2020

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).

Loading

@texastoland
Copy link

@texastoland texastoland commented Apr 24, 2020

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.

Loading

@chenglou
Copy link
Member

@chenglou chenglou commented Apr 24, 2020

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.

Loading

@chenglou chenglou closed this Apr 24, 2020
@Starcounter-Jack
Copy link

@Starcounter-Jack Starcounter-Jack commented Apr 24, 2020

@hoichi You are right regarding Elm.

Loading

@Starcounter-Jack
Copy link

@Starcounter-Jack Starcounter-Jack commented Apr 24, 2020

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

Loading

@vasco3
Copy link

@vasco3 vasco3 commented Oct 8, 2020

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

Loading

@mweichert
Copy link
Contributor

@mweichert mweichert commented Oct 8, 2020

Loading

@kevinbarabash
Copy link

@kevinbarabash kevinbarabash commented Nov 22, 2021

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?

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet