@bhauman or anyone else who might be interested, I figured it out, webpack config needs this: devtool: 'source-map' to fix problem above

Source that was directly relevant and helped: https://github.com/aws-amplify/amplify-js/issues/5660

It affected around 10 of my NPM dependencies, out of about 30. Did not look into the characteristics of the ones that did not work, could do that if any of the core people are interested in solutions to this problem.

Hi yall, Question: when my app is compiled, it seems to run in the window scope. Is there a way to like wrap it in a Immediately Invoked Function Expression (IIFE) or similar?

because my cljs script is being embedded in websites beyond my control, this is why I ask.

ie. it sometimes conflicts with other scripts in there

or should I approach this in a different way?

Wait. This is probably it: https://clojurescript.org/reference/compiler-options#output-wrapper

Yes it was, :output-wrapper true did it. Thanks rubber ducks!

is there a way to get the closure compiler to output a warning whenever it encounters a js property that isn't defined in an extern? is this even a good idea?

in shadow-cljs there is shadow-cljs check the-build but it generates very many false positives and a lot of noise so its not super useful. it does warn about all those cases though.

so generally not a good idea for CLJS. only really works if you have fully typed code like the closure-compiler prefers.

we're mostly bashing DOM apis, which should be fully typed

which flags does check-the-build set, @thheller? i'd like to give it a go

well but the CLJS code you are doing this with isn't typed 😛

true true 😉 but we can provide hints

can't really do this without shadow-cljs. its not just a couple compiler options. shadow-cljs also feeds additional info to the closure-compiler. otherwise you'll end up with thousands of warnings for cljs.core alone

something like the *warn-on-infer* for file scope, for example..

we're using shadow, i'll give it a go

shadow-cljs basically just runs the closure-compiler with typechecking enabled (which usually isn't)

see what you mean about false positives.. loads of warnings for arity-1 parseInt for example, which I'm not even sure is an error in the browser.. (the radix behaviour should be stable there..)

how about some kind of regex for filtering the warnings? bit like the test ns matching

shadow-cljs check :build --filter=my.app.ns or so

can write that up as a ticket if think it's worth looking at

dunno, in my experience check output is only useful as very last resort. externs inference usually catches most things already so that should be preferred

FWIW the parseInt for example SHOULD always have 10 as the second arg if you want to be safe

> An integer between 2 and 36 that represents the radix (the base in mathematical numeral systems) of the string. Be careful—this does not default to 10!

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt

thats why closure complains 😛

to give a concrete example, i'm upgrading a JS library that renamed a property that exposed a promise from complete to done - promises can be resolved with undefined just fine, so it wouldn't throw any kind of error as if we tried to invoke it as a function.

heh, it's a classic (parseInt) - yay for octals etc.

point taken

well for JS libraries you wouldn't get a warning for this at all

I wrote an extern for it, and provided hints in cljs.

closure can't tell if its complete or done since it doesn't know the type of the value you are operating on

those hints you provided in CLJS are not transferred to be visible by closure

if you mean ^foo hints, only works via :jsdoc hints

(defn thing [^js/myThing x]
  (.-foo x))

so, in this example, .-foo might get mangled?

yeah closure doesn't see that. it just causes shadow-cljs to generate externs for foo

ah hah!

so, shadow will assume that the programmer has done the right thing, and generate an extern for the property foo?

as soon as you add a ^js hint it will be treated as such and collect externs for all property access yes

Any recommendations on HTTP client libraries compatible with both CLJ and CLJS? Or am I better off writing something that handles both on my own?

Hi all, is possible to add an :after style dynamically? I am using reagent and essentially, I have tried doing {:style {:after {… attrs …}}

@gekkostate you can toggle a CSS class which has the :after style