Finally got around to create a repro for broken source-mapping when targeting :node-libray (and to an extent :node-script): https://github.com/martinklepsch/shadow-src-map-issues Did anyone else encounter unexpected results with source maps and these targets?

@martinklepsch private repo? it get a 404

@thheller oops, fixed!

also there is no package.json so I don't know which version you tried 😛

I tried latest but somehow

npm install --save-dev shadow-cljs

yeah need to package.json. install never creates it

done

btw dunno if you tried but

$ node -r source-map-support/register -e 'var x = require("./functions/index"); x.throw()'
/mnt/c/Users/thheller/code/tmp/shadow-src-map-issues/functions/index.js:253
556298533),Ve=new Tb(null,"more-marker","more-marker",-14717935);function qf(a){throw Error(["[",G.a(a),"] Fabricated example exception"].join(""));}var rf=["icebreaker","server","util_reduced","something_that_throws"],sf=aa;rf[0]in sf||"undefined"==typeof sf.execScript||sf.execScript("var "+rf[0]);for(var tf;rf.length&&(tf=rf.shift());)rf.length||void 0===qf?sf=sf[tf]&&sf[tf]!==Object.prototype[tf]?sf[tf]:sf[tf]={}:sf[tf]=qf;
                                                                                ^

Error: [api-endpoint-error] Fabricated example exception
    at qf (/mnt/c/Users/thheller/code/tmp/shadow-src-map-issues/functions/cljs/core.cljs:10747:20)
    at Object.throw (/mnt/c/Users/thheller/code/tmp/shadow-src-map-issues/functions/goog/base.js:169:3)
    at [eval]:1:46
    at Script.runInThisContext (vm.js:96:20)
    at Object.runInThisContext (vm.js:303:38)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (internal/modules/cjs/loader.js:688:30)
    at evalScript (internal/bootstrap/node.js:582:27)
    at startup (internal/bootstrap/node.js:267:9)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:739:3)

I don't have babashka installed so can't run your other scripts 😛

if that the same result you get though? it does indeed seem incorrect

I guess this fails https://github.com/martinklepsch/shadow-src-map-issues/blob/master/view-source.clj#L1

doesn't matter though. source-map-support seems to show the issue just fine

Seeing the similar results with -r source-map-support/register

Do you want me to open an issue for this?

sure

@martinklepsch suppose this looks better 😉

Error: [api-endpoint-error] Fabricated example exception
    at Object.throw (/mnt/c/Users/thheller/code/tmp/shadow-src-map-issues/functions/icebreaker/server/util_reduced.cljs:4:30)
    at [eval]:1:46

That indeed looks better 🙂

@martinklepsch fixed in 2.10.5

This is probably a horrible idea and I probably won't pursue it, but let's say I want to allow my self-hosted cljs app to be distributed as just html+js files with no server. I then wouldn't be able to make any ajax calls due to cross origin policy. I believe I could support this by replacing ajax calls with dynamically adding a script tag to the DOM linking to the a js file that puts the json in a variable. To do this with shadow, in theory, could I just add a postprocessing step to put index.transit.json and the bootstrap analysis files into js files, and then rewrite a selfhost load/`init` function based on the current shadow browser load mechanism? Or is there something obvious I'm missing

you mean let the user load everything from local disk?

yes

no clue how that would work but I guess you could also create one gigantic .html file that just already contains everything

same thing I do for the build-report html files

I believe I could append a <script src="x.js"> tag with the source being

var transit123 = ...

i'll check out the build-reports, thanks!

don't have to do that

you can create <script type="my-transit" data-key="some-name">... transit contents here ...</script> (or <template>) tags

then when its time to parse them just look it up by data-key or so and parse the text

don't have the browser eval it

I was thinking for performance reasons though to defer the loading until needed, but I might be overthinking that

if its not script tags have a non-js type the parser just skips over them. that should be pretty fast and you are talking about local access so no network concerns.

actually parsing the transit you can delay however long you like

oh cool, didn't know that

just gotta be careful whats in those transit strings. will get you into trouble if there is a {:foo "</script">"} transit encoded value in there since the HTML parser is just looking for </script> and doesn't to any kind of other parsing

might need base64 encoding or so

that's definitely good to know 🙂

you can try the other method too of course, just wrap the transit files JsonP style with a function call that registers them somewhere

yeah it does seem the big file might be a bit more straightforward for now

might be scary to hand someone a 20mb .html file though 😉

yeah that was my initial thought haha