Previously, we've used lein extern to generate them, and if I run that and include those externs in the build, its all fine.

Otherwise I get "Uncaught Module not provided: 10"

(I now always get that error, can't get the app to launch anymore.)

you can create a release build with npx shadow-cljs release app --pseudo-names. that usually makes it easy to track what was renamed and which externs you would need.

don't know what you are doing exactly so can't provide more tips

the module not provided I'm guessing you get from either some bad cache or trying to mix files from different builds?

or are there maybe other errors, before or after which may lead to this one?

hm, so building with --pseudo-names fixes it

any idea how to proceed from there?

do you use clj->js or js->clj alot?

pseuo-names really shouldn't fix anything. if it does it likely means that the conflict is on a very short property name

the closure compiler shortens things to .a .b etc frequently

with pseudo-names that becomes .$whateverItWasBefore$

which is less likely to cause conflicts

the only known issue I'm aware of regarding this is with js->clj

what kind of externs did you have before? I don't know that lein extern is so dunno what that generaetd

I do use clj->js and vice versa, not sure if a lot, but I think not

when does this become an issue?

one issue I just saw:

(.on win "close" #(do
                            (.set Settings "winBounds" (.getBounds win))
                            (when-not (contains? @!can-close window-id)
                              (.preventDefault %)
                              (async/put! event-queue
                                          {:window-id window-id
                                           :payload [:window/close-requested]}))))

but it does crash and can be fixed by ^js'ing win and Settings (maybe either is sufficient, have only tested both)

this should definitely give you externs warnings?

did you set :infer-externs in your build config somewhere?

or are you using some ultra ancient shadow-cljs version?

I did get a lot of warnings without setting any :infer-externs option – after silencing all warnings, this one remained (I saw that the default was what I wanted)

2.20.16

I just recompiled with explicit :infer-externs :auto and still no warnings

what are win and sSettings in the above?

(I mean no extra warnings)

what does "extra" mean?

when I ran the build the first time I did get a lot of warnings that I silenced

... source code ...

hm, it seems the win is tagged as js in the let, but that doesn't carry through to the closure?

win isn't tagged at all

should be ^js win (BrowserWindow. (clj->js opts))

and you are tagging a bunch of stuff that doesn't need tags at all

yeah, I was tagging lots of stuff to debug this

but where do I trip up the warnings?

which warnings?

shouldn't it give me a warning that I'm not tagging win?

I'm still guessing mostly in the dark about what you are asking me

so please be specific 😛

no, you should get warnings about locations where it cannot infer externs

tagging win once in the start should pretty much be enough for most things I see there

its always best to tag the name symbol, not the form that creates it

got it

win ^js (BrowserWindow. (clj->js opts)) is not ideal since there are a few places in the compiler that lose type hints. I'm not sure this is one but to be sure just move it to the left

> when I ran the build the first time I did get a lot of warnings that I silenced

what do you mean by silencing?

I mean I tagged the locations it gave me

ok

should I try reverting the tagging, go through the inference warnings again, but tag the symbols, not the expressions and see if that fixes it? or is that not the cause?

I don't know the cause. I haven't seen the exact error. I'm guessing in the dark

ok, I'll try that

and report back

(at this point, just getting runtime errors related to non-externed symbols, fwiw)

but without getting non-inferrable externs warnings for those symbols

no compile errors etc.

update: I diligently fixed inference warnings the errors by tagging the named symbol where it appears first. this fixed the build 🎉 (I was led astray originally because of broken builds due to caching)

that said: I get a lot of runtime errors due to missing externs

there definitely is some kind of issue with inference of JS objects that get passed into a function through a clj map

e.g.

(defn do-stuff [system]
  (let [{:keys [Dialog]} system]
    (.doSomething Dialog "foo")))

this should absolute 100% generate a warning

any way I can debug this?

do you mistakenly set :infer-externs true in your build config?

or somewhere else mess with *warn-on-infer*?

{:editor {:target :browser
           :output-dir "resources/public/js/compiled/"
           :modules {:editor {:entries [editor.core]}}
           :externs [
                     "resources/externs/react.ext.js"
                     "resources/externs/react-dom.ext.js"]}
  :analyzer {:target :browser
             :output-dir "resources/public/js/compiled/"
             :modules {:analyzer {:entries [analyzer.core]
                                  :web-worker true}}}
  :app {:target :node-script
        :main app.core/main
        :output-to "resources/public/app.js"}
  }

this is our :builds key – we only h ave source-paths and dependencies set otherwise

just grepped for warn-on-infer and nothing came up

hmm wtf

I just took your code and code no warning either

let me check

hmm this indeed seems to be a pattern that never produces any inference warnings

so dot-interop on anything destructured in a let binding

anything I can do to help with that? or would you recommend tagging manually for now as a fix is not straightforward?

you can upgrade to 2.20.17. that should give you warnings for this pattern

damn

🙌🙌🙌

got lots of new warnings, thanks! fyi, injecting symbols like Path or Url using this pattern does still not trigger warnings, though. (but e.g. FS App Dialog do trigger warnings)

and it seems it sometimes only triggers one (local) occurrence, though not for later injections in different defn's further down the file

not everything requires externs so that might be alright