Fork me on GitHub
#shadow-cljs
<
2023-02-14
>
mokr06:02:39

Hi, I’m seeing infer warnings for Reagent’s with-let macro when using shadow-cljs versions relying on recent versions of com.google.javascript/closure-compiler-unshaded. Some googling yesterday gave me the impressing that Reagent https://github.com/reagent-project/reagent/issues/420 in 2019. This code is from the Luminus template and if I’m not mistaken it has been working for years:

30 | (defn navbar []
  31 |   (r/with-let [expanded? (r/atom false)]
---------^----------------------------------------------------------------------
 Cannot infer target type in expression (. with-let71820 -generation)
--------------------------------------------------------------------------------
  32 |     [:nav.navbar.is-dark>div.container
  33 |      [:div.navbar-brand
A combo that does not emit warning:
[com.google.javascript/closure-compiler-unshaded "v20220803"]
[thheller/shadow-cljs "2.20.0" :scope "provided"]
one that does:
[com.google.javascript/closure-compiler-unshaded "v20230103"]
[thheller/shadow-cljs "2.20.20" :scope "provided"]
I’m not sure which project/lib should correct the issue, but it’s keeping up with shadow-cljs that introduce it in my project. Is there something I can do to avoid these warnings apart from not using with-let?

thheller06:02:54

I'm not sure how you are changing that version, but shadow-cljs shouldn't even start with that combo

thheller06:02:17

and more importantly it the closure compiler has nothing to do with this issue at all?

thheller06:02:09

I guess you can create a externs/your-build.txt with generation as the content. that should make it shut up

mokr06:02:03

Which combo were you referring to? I’m always following the versions specified for shadow-cljs on Clojars. Did I mess up?

thheller06:02:54

[com.google.javascript/closure-compiler-unshaded "v20220803"]
[thheller/shadow-cljs "2.20.0" :scope "provided"]

thheller06:02:28

this should break?

mokr06:02:01

No, that one works.

mokr06:02:43

When I noticed the warning with 2.20.20, I started going backwards to find one that worked.

thheller06:02:27

this contained a breaking change and should make the older closure compiler version incompatible

thheller06:02:57

but regardless. I know what the issue is and it is fixed in reagent, just waiting for a release

thheller06:02:05

until then manually create the externs

thheller06:02:17

or use the combo if it works for you

mokr06:02:21

Thanks, let’s leave it at that. My code works, so I can live with the warnings until Reagent releases. Thanks for the quick reply as well!

Galaux09:02:51

Hi y'all, hi @thheller (and thanks for all your work 🙂), I'm struggling to get a base shadow-cljs+expo project working with hot reload and was wondering if you could spot something I would have missed. I started with your https://github.com/thheller/reagent-expo repository but figured that after some degree of nested components, code changes wouldn't be reloaded on my app. https://github.com/galaux/reagent-expo-nested-components reproduces my problem: it's based on https://github.com/thheller/reagent-expo/pull/12 (project won't build otherwise). I've added 3 nested components such that rootonetwothree. I run npx shadow-cljs watch app and npx expo start --clear --web then visit http://localhost:19006 on my browser. Code changes to root, one or two are effectively hot reloaded right away but not the ones to three. This looked similar to https://github.com/thheller/shadow-cljs/issues/544 where you advise to use the [root {:x (js/Date.now)}] trick that I do use (if I open app/index.js I can see the generated code bears the very last changes, they are just not rendered it seems). For the record, I've also read your blog post https://code.thheller.com/blog/shadow-cljs/2019/08/25/hot-reload-in-clojurescript.html that, unless I'm mistaken, I've followed. Interestingly enough: this problem doesn't show if I run my app using the phone app expo-go. Can you spot anything I would've missed?

thheller09:02:11

this is more of a reagent question that it is shadow-cljs

thheller09:02:47

at some point reagent probably just decides that nothing has changed and stops rendering

thheller09:02:15

the [root {:x (js/Date.now)}] trick only helps to force it to render the root, it doesn't affect deeper levels

thheller09:02:29

you can change :devtools {:reload-strategy :full} in the build config

thheller09:02:52

that'll make it always reload all files, which can become rather slow but helps for cases such as this

Galaux09:02:30

Testing :devtools {:reload-strategy :full} but that doesn't seem to change anything.

Galaux09:02:12

> this is more of a reagent question that it is shadow-cljs Understand …

thheller09:02:21

as long as shadow-cljs calls the :dev/after-load fn its job is done

Galaux09:02:09

Right, that makes sense! 🙂

thheller09:02:13

I don't use react-native/expo myself, so I'm a bit out of the loop when it comes to internals

Galaux09:02:12

No problem 🙂, I'll try to see what could be going wrong reagent wise.

Galaux09:02:37

Thanks for your time !

hifumi12310:02:49

Is there a command equivalent to lein deps for shadow-cljs? That is, a command that does nothing but download dependencies of a project My use case is for separating the dependency downloading and compilation steps in a Dockerfile, so that images can build much quicker rather than having to wait up to a minute to download JARs per build

thheller10:02:57

npx shadow-cljs classpath works

thheller10:02:32

cache your ~/.m2 folder between docker runs, then it won't have to redownload the deps all the time

thheller10:02:53

also a volume or just mounted

hifumi12310:02:08

Makes sense. Thanks!

Braden Shepherdson22:02:00

several folks at Metabase are having issues with the shadow-cljs server not exiting when you ctrl-C a watch. this seems to have started lately, either from moving from deps in shadow-cljs.edn to deps.edn, or more recently when bumping the version from 2.19.6 to 2.20.20.

thheller06:02:31

regarding watch nothing has changed for years, and definitely not between 2.19.6 or 2.20.20

thheller06:02:48

did you maybe start something your own setup?

thheller06:02:37

note that the server isn't supposed to exit if the watch only joined one? if one was started previously that will keep running. either a npx shadow-cljs watch or npx shadow-cljs server? could be they have a lingering process they forget about?

Braden Shepherdson12:02:10

a few of the scripts do shadow-cljs restart && shadow-cljs release app or shadow-cljs restart && shadow-cljs watch app etc. perhaps they should be gentler? dropping that restart and just letting watch start the server seems to work okay.

thheller12:02:08

why all the restarting?

thheller12:02:30

restart starts a background server, so easy to forget thats running

thheller12:02:18

you can just create a release build using the existing server?

thheller12:02:27

ie. while watch is running?

thheller13:02:31

I usually recommend running shadow-cljs server in some place. then all other commands will use that server. or you may also control the watch via the ui at http://localhost:9630

thheller13:02:06

if server runs in a dedicated terminal its easy to keep track off and kill, also makes the occisional improperly routed output visible

Braden Shepherdson13:02:16

much of the team isn't actively working on CLJS things, and just does yarn build-hot, which runs dev-mode watches with shadow-cljs and webpack to keep the JS code live-updating. starting a server in a separate terminal in that case isn't great. I think it was the background server from restart causing the issues. the watch is slow to start, but most people only restart that process once or twice a day, so that's fine. I think we can just drop the restarts from the main commands.

thheller13:02:03

yeah, unless you also use start/stop don't use restart 😉