In anger, but stack traces will be correctly mapped soon 😄 https://github.com/anmonteiro/lumo/pull/349

@richiardiandrea If you end up bundling the core namespace map files, I’d recommend taking a look at what Planck does. In particular, delay loading them until they are actually needed (when a stack trace needs to be mapped), because they are expensive to load. Also, Planck reduces the source map files to the bits that actually matter, so when they are loaded, this is done nearly instantly, as opposed to taking several seconds.

@mfikes thanks! I think @anmonteiro was already looking at that 😄 My PR at the moment just enables inline map parsing from the :source-maps key that as you saw in #cljs-dev was bumpy. It works with workarounds and some things maybe not fully understood on my side (the ?rel= for instance, seems unnecessary in node)

Ahh, cool. Yeah, I wonder if Node even honors the inlined source maps. It was my vague impression that they could be parsed out by browsers and used if an exception occurs there, but JavaScriptCore in Planck definitely treats it as an unecessary comment. 🙂

FWIW, the source map compression code is here: https://github.com/mfikes/planck/blob/master/planck-cljs/src/planck/repl.cljs#L1245-L1259

@mfikes what do you think about tagging commits/issue with a label that says "look lumo/planck", this might be interesting for you

I was scanning the commits today for things to port over

and it is pretty time consuming 😄

Sounds fine with me. One thing I tend to do, which might be similar, is tag issues as being upstream.

But, there are a class of issues that are not upstream and affect both Lumo and Planck.

yep, this is not really upstream though, is more "lateral" 😄

exactly

I don’t mind actually logging an issue in Lumo when I find one in Planck.

oh that would be fantastic

In other words, I don’t mind trying a quick repro and logging one in Lumo’s issue list.

ok then...I think we don't need a label if we do that

so @mfikes then one thing I had to do is https://github.com/anmonteiro/lumo/pull/349/files#diff-4da6b6777b07770bfe3ffbd39a773e33R566

but I don't know if you need it as well

see the two issues I opened in CLJS as well: CLJS-2492 & CLJS-2493

Hmm. Not following completely @richiardiandrea. I’ll look more deeply. For now, this Planck behavior seems correct:

(ns foo.user-with-underscores)

(defn try-it []
  (ffirst 1))

cljs.user=> (require 'foo.user-with-underscores)
nil
cljs.user=> (foo.user-with-underscores/try-it)
1 is not ISeqable
	seq (cljs/core.cljs:1212:20)
	first (cljs/core.cljs:1221:15)
	ffirst (cljs/core.cljs:1733:11)
	foo/user-with-underscores/try-it (foo/user_with_underscores.cljs:3:29)

@mfikes looks correct yep! Are you populating :source-maps in any way. I completely rely on what's set by ClojureScript. There is something else to say, I might have fixed the problem without knowing the cause

I don’t recall. There is plenty of stuff I have Planck do to work around various things.

actually I am thinking now that the :file key that I pass to *load-fn* might be used in the :file of the source map...so lumo maybe is not passing it correctly or something...I will check js.cljs again