shadow-cljs

Roman Liutikov 2025-02-13T21:08:09.001639Z

I found there's :closure-configurators compiler option in shadow for injecting custom Closure compiler passes, but it doesn't work when declared in shadow-cljs.edn would be great if that worked

thheller 2025-02-13T21:09:55.486139Z

what would you do with that?

Roman Liutikov 2025-02-13T21:11:13.936359Z

this https://github.com/pitch-io/uix/pull/213/files a custom compiler pass to post process library specific code

Roman Liutikov 2025-02-13T21:13:10.653209Z

In this specific case I'd normally do it via constants table in cljs, but since in shadow it's implemented as closure compiler pass, I had to implement my own as well

thheller 2025-02-13T21:17:05.939519Z

you never answered what the point of the constants table is? I just do not get what this is doing?

Roman Liutikov 2025-02-13T21:22:31.552049Z

ah right, so this is for UIx, React wrapper. The idea is to find compile time constant elements in UI components and hoist them to global scope. Basically deduplicating and caching elements across the codebase. Now I'm thinking that it actually might be doable from a macro

thheller 2025-02-13T21:24:09.082699Z

ah, I think you want analyze-top 😛

thheller 2025-02-13T21:25:19.783649Z

basically the ability of a macro to inject something before the current top level form

Roman Liutikov 2025-02-13T21:28:58.601699Z

yeah something like that, it should be doable already

(defmacro defui [name args & body]
   `(do
       ~inject-here
       (defn ~name ~args ~@body)))
and then have a global registry to deduplicate injected stuff, but then how do I clean the registry after every compilation (when running shadow in watch mode)?

thheller 2025-02-13T21:30:09.734369Z

yeah if its a just a top level def already you do not need any special magic because the def can just do it already

thheller 2025-02-13T21:30:40.577569Z

and I think you might be overvaluing the de-duping. I mean how likely is it to get the extact same element multiple times?

thheller 2025-02-13T21:31:20.901739Z

the important bit is that the structure stays identical, not a singular node in that structure

Roman Liutikov 2025-02-13T21:31:37.549159Z

no idea, just want to see if it's possible to dedupe at compile time as well

thheller 2025-02-13T21:31:52.939979Z

I experimented quite a bit in that area and my results were that deduping was pointless

thheller 2025-02-13T21:32:50.999849Z

basically only ended up removing dumb blank :div elements

thheller 2025-02-13T21:35:43.647539Z

regardless. I'm open to opening access to :closure-configurators but since it currently requires a secondary option to specify which compile phase to add this in how would this look?

thheller 2025-02-13T21:36:27.917189Z

.addCustomPass closure-opts CustomPassExecutionTime/BEFORE_CHECKS that second argument I mean

thheller 2025-02-13T21:37:12.156719Z

I guess it could be metadata and the build config just taking a qualified symbol

thheller 2025-02-13T21:37:48.740469Z

:closure-configurators [uix.optimize/thing] or so

thheller 2025-02-13T21:38:34.827019Z

oh nvm. you do that in the function anyway

👍 1
thheller 2025-02-13T21:38:54.024579Z

so just this :closure-configurators [uix.optimize/thing] would be enough

Roman Liutikov 2025-02-13T21:39:56.719259Z

Yep 👍

thheller 2025-02-13T21:40:40.302879Z

technically you can already do this in a build hook

thheller 2025-02-13T21:41:02.991119Z

it gets full access to the build and you can do it in :optimize-prepare stage

thheller 2025-02-13T21:41:42.279669Z

because thats runs after the setup fn you are currently hacking

thheller 2025-02-13T21:42:10.989059Z

so :build-hooks [(uix.optimize/inject)] or so

thheller 2025-02-13T21:43:31.923469Z

:shadow.build.closure/compiler-options in the build state holds the closure compiler options object

thheller 2025-02-13T21:44:08.181899Z

:shadow.build.closure/compiler the closure compiler instance

Roman Liutikov 2025-02-13T21:44:27.564999Z

Oh right, good point