shadow-cljs 2024-03-29 | Slack Archive

lassemaatta07:03:25

We've recently started to intermittently seeing hundreds of build warnings wrt. interpreting. Running lein clean to remove the target directory seems to fix this for a while. I suspect we've updated some dependency or added some npm library which might trigger this, but this is just a guess. Any idea what the real cause might be?

WARNING: interpreting by default at #'cljs.analyzer/*cljs-file*:125:1
attrs64469
Inferred tag was: #{any}

EDIT: This has nothing to do with shadow-cljs, the warning is generated by rum.

thheller07:03:39

I don't know what that is. not an error message I have ever seen before, or being produced by shadow-cljs

lassemaatta07:03:42

We're still using a rather old version of shadow-cljs, 2.20.7, but this seems to occur with newer versions at all

lassemaatta07:03:57

oh, interesting

lassemaatta07:03:40

In that case I need to direct my investigations elsewhere, thanks!

lassemaatta07:03:13

(partially) solved just in case someone else ever needs this: the warning is coming from rum (https://github.com/tonsky/rum/blob/005a2f067178808f92dc796f2c867cc152793279/src/daiquiri/compiler.clj#L23). I was too focused on the build tool to think about anything else 🙂

thheller07:03:43

seems like that is missing a @ so that you actually see what file it is complaining about?

thheller07:03:11

as in (println (str "WARNING: interpreting by default at " @(requiring-resolve 'cljs.analyzer/*cljs-file*) ":" line ":" column))

lassemaatta07:03:02

yeah, looks like it. Not much point in printing out the var a hundred times

thheller07:03:03

or better yet (println (str "WARNING: interpreting by default at " (:file env) ":" line ":" column))

3starblaze12:03:14

Hello! I think I found a bug in shadow-cljs. I was deploying my app and when I checked out the built version, I got a message that something is not found. I checked out about infers and it seemed like there is no inference problem at my side. I found out the real reason, here's a diff:

-    (.registerElement ElementFactory.Instance widget-name (fn [] (Model.)))
+    (.registerElement (.-Instance ElementFactory) widget-name (fn [] (Model.)))

-    (.registerQuestion ReactQuestionFactory.Instance widget-name render-fn)))
+    (.registerQuestion (.-Instance ReactQuestionFactory) widget-name render-fn)))

It seems like ReactQuestionFactory.Instance is not treated as (.-Instance ReactQuestionFactory) and so that info is thrown away.

thheller12:03:50

strictly speaking ReactQuestionFactory.Instance is not valid

thheller12:03:10

but yes, this is known to lose the js hint, pretty sure its not shadow-cljs though. I think thats part of the cljs.analyzer code

thheller12:03:53

might be wrong though. haven't looked into it

3starblaze12:03:53

Ah okay, maybe it's possible for shadow-cljs to produce a warning when it encounters something like this? It did work on dev, so I didn't pay much attention to that little fragment.

3starblaze12:03:23

And why wouldn't it be valid? If it runs it should count as valid or is there something I am missing?

thheller12:03:53

well, I guess its official now given that it has been in there since forever

thheller12:03:02

but it basically only ever worked as an accident

3starblaze12:03:38

so it's an accident that my former code worked?

thheller12:03:00

no, it is an accident ReactQuestionFactory.Instance is accepted as a valid symbol

thheller12:03:20

in clojure this is not allowed

👍 1

thheller12:03:45

symbols with dots have a long history of problems 😛

thheller12:03:23

the code for all this is in cljs.analyzer

3starblaze12:03:26

yeah, to be honest it is weird how I even ended up with that symbol in code in the first place but thanks for the quick reply

thheller12:03:46

so not something I can easily address in shadow-cljs. at least I think so. as I said I have not looked into this

thheller12:03:52

could be an easy fix from the shadow-cljs side

👍 1

3starblaze11:03:02

oh yeah, I just remembered about js/console.log which is a common thing to do in cljs. Obviously this kind of issue wouldn't arise because it's a builtin function but it does seem like there is nothing problematic with dots in symbols

thheller12:03:45

this works because js/* is all automatically tagged as JS and creates externs if needed

thheller12:03:27

I'm not saying this can't or shouldn't be fixed

thheller12:03:31

just that I haven't looked into it

👍 1

2024-03-29

Channels