# Mapping a JS stack-trace back to Elm
**URL:** https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643
**Category:** Learn
**Created:** [August 15, 2018, 10:25pm UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643 "2018-08-15T22:25:35Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@Seanny123](https://discourse.elm-lang.org/u/Seanny123)
#### Post date: [August 15, 2018, 10:25pm UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/1 "2018-08-15T22:25:35Z")
I’m trying to get started on the huge project called Sketch-n-Sketch. I found some behaviour which causes an error, which I can see in the Chrome developer console. The error is cause by the program creating some invalid SVG output. I can click the stack-trace to find where the error is caused on in the JS output file, however I’m having a hard time finding where the error is being caused in the Elm code.
**How does one typically map from a JS error to an Elm file?**
# What I’ve tried
I feel like I might be asking for an Elm debugging tutorial, since I’ve only written small programs while going through the Elm tutorial. I’ve seen you can apparently use `elm-make --debug`, but when I try to do this, a bunch of ports aren’t found. So I think it doesn’t apply to this case? However, the project seems to be sprinkled with `Debug.log` and `Debug.crash` statements, so maybe there’s so may to get this to work?
I also know that currently source-maps don’t exist for Elm, which is how I usually accomplished this when I used TypeScript.
---
### Author:  [@Seanny123](https://discourse.elm-lang.org/u/Seanny123)
#### Post date: [August 16, 2018, 12:43am UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/2 "2018-08-16T00:43:34Z")
As a kind of non-answer which solved, my problem, I now understand how `Debug.log()` can be used to do basic `print` debugging. This in turn allowed me to figure out which files were being called. Specifically, given the utility function in `Utils.elm`:
```auto
log : String -> ()
log s = Debug.log s ()
```
You can add:
```auto
let _ in Utils.log "debug msg" in
```
Basically anywhere in your code to get output to the web console. This seems obvious in hindsight, but for some reason it wasn’t clear to me initially?
I don’t know how I got this idea it depended on the `--debug` build option, but it doesn’t.
---
### Author:  [@akoppela](https://discourse.elm-lang.org/u/akoppela)
#### Post date: [August 22, 2018, 2:51am UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/3 "2018-08-22T02:51:36Z")
Why not use `Debug.log` directly?
---
### Author:  [@jerith](https://discourse.elm-lang.org/u/jerith)
#### Post date: [August 22, 2018, 5:49pm UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/4 "2018-08-22T17:49:06Z")
Yeah, the fact that `--debug` isn’t needed to turn on `Debug.log` has been hard for me to remember too. I’ve had some debug statements show up in profiling, even (since `toString` is expensive for large data structures). So I wonder if `Debug.log` _should_ be a no-op without `--debug` … ?
---
### Author:  [@mattpiz](https://discourse.elm-lang.org/u/mattpiz)
#### Post date: [August 23, 2018, 6:59am UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/5 "2018-08-23T06:59:44Z")
I don’t know what the future of elm 0.19 will be, but at the current state of elm debugger I think we should keep it in normal compilation, especially since now we also have the `--optimize` option.
The performance cost implied by the `--debug` option (which keep the full history of events) is simply to high to only allow `Debug.log` in this mode.
Maybe `--debug` should be `--time-travel`.
---
### Author:  [@crazymykl](https://discourse.elm-lang.org/u/crazymykl)
#### Post date: [August 23, 2018, 1:35pm UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/6 "2018-08-23T13:35:12Z")
> [@mattpiz](#):
>
> Maybe `--debug` should be `--time-travel` .
I disagree with this nomenclature; the debugger no longer allows actual time travel, only rewinding to view past states.
---
### Author:  [@Viir](https://discourse.elm-lang.org/u/Viir)
#### Post date: [August 23, 2018, 4:02pm UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/7 "2018-08-23T16:02:42Z")
> [@crazymykl](#):
>
> the debugger no longer allows actual time travel, only rewinding to view past states.
Did it support branching off in the past? Or something else that is not supported anymore? 🤔
---
### Author:  [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [August 23, 2018, 4:06pm UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/8 "2018-08-23T16:06:32Z")
> [@Viir](#):
>
> Did it support branching off in the past? Or something else that is not supported anymore? 🤔
It used to, but someone went back in time and distracted the developer with a shiny new project as he was about to submit that patch, and it never made it into the release. 😉
---
### Author:  [@jerith](https://discourse.elm-lang.org/u/jerith)
#### Post date: [August 23, 2018, 4:17pm UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/9 "2018-08-23T16:17:56Z")
Yeah, I was glad to see that `--optimize` turns of `Debug.*` in 0.19.
---
### Author:  [@mattpiz](https://discourse.elm-lang.org/u/mattpiz)
#### Post date: [August 24, 2018, 4:46am UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/10 "2018-08-24T04:46:36Z")
Maybe `--record` then is better. Though I could argue that the best time travel scenarios are the one that do not change past events 😄
---
### Author:  [@system](https://discourse.elm-lang.org/u/system)
#### Post date: [September 3, 2018, 4:48am UTC](https://discourse.elm-lang.org/t/mapping-a-js-stack-trace-back-to-elm/1643/11 "2018-09-03T04:48:24Z")
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.