Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2022-11-16

Channels

#shadow-cljs
<
2022-11-16
>
thheller08:11:55

@martinklepsch you said "no" to my question about :js-package-dirs, but then basically confirmed that you do in the next sentence? I'm confused by what you mean there. If you have :js-package-dirs ["client/node_modules"] or something then the node-libs-browser or shadow-cljs package needs to be installed in that node_modules folder?

thheller08:11:24

oh wait I guess I just read that wrong. you use one for everything, with only one package.json total?

👍 1
Quentin Le Guennec08:11:36

Can I specity per-build deps.edn aliases?

thheller08:11:23

no. why would you want to?

Quentin Le Guennec09:11:58

Because I got two app.client in different paths for two different builds. In src/website and src/launcher

Quentin Le Guennec09:11:51

I would like to have the :website deps.edn alias (with extra path src/website associated with the :website shadow.cljs build, then same with the :launcher build

thheller09:11:50

I would very very strongly suggest to keep everything on one source path and instead have separate app.website and app.launcher or whatever namespaces that do distinctive things

thheller09:11:05

then use separate builds to have control over what gets compiled

Quentin Le Guennec09:11:24

I kinda don’t want that

thheller09:11:59

then your only option is to drop the shadow-cljs command and run via clj directly

thheller09:11:29

shadow-cljs watch website is the same as clj -A:whatever:aliases -M -m shadow.cljs.devtools.cli watch website

thheller09:11:40

but be aware that this comes with a long list of caveats and problems

thheller09:11:48

so I strongly recommend not doing this

Quentin Le Guennec09:11:14

Are those problems documented somewhere?

thheller09:11:15

each build needs to be launched separately that way

thheller09:11:56

aliases control the classpath. the JVM can only have one classpath. so any changes to the classpath require starting a new jvm

thheller09:11:13

thus you will have 2 independent instances if you want two builds to run and the same time

thheller09:11:26

they are going to compete and interfere with each other since shadow-cljs is not designed for this

Quentin Le Guennec09:11:38

I will follow your initial suggestion, then

thheller09:11:06

if you ask me having 2 definitions for the same namespace is horrible and makes even using my editor annoying, not even accounting for build issues

thheller09:11:52

you can still easily move the stuff that those namespaces share into a shared namespace and keep the relevant specific parts in each

Quentin Le Guennec09:11:01

Yeah, I guess that works as well

colinkahn20:11:22

Are there any known issues with the Inspect feature of shadow-cljs UI not datafying?

colinkahn20:11:20

I am trying: 

(comment
 (require '[clojure.core.protocols :as p])

 (extend-type js/HTMLDivElement
   p/Datafiable
  (datafy [o]
    (.-outerHTML o)))

 (def div (doto (js/document.createElement "div")
            (.appendChild (js/document.createTextNode "Hello World"))))

 (p/datafy div) ;; "<div>Hello World</div>"

 (tap> div) ;; [object HTMLDivElement]]

 (def m (with-meta {} {`p/datafy (fn [_] :map)}))

 (p/datafy m) ;; :map

 (tap> m) ;; {}
 )
Which the tapped versions in the UI don't datafy when they're in the "viewer" (after clicking on them).

thheller20:11:43

nothing I'm aware of. I'd sort of expect this to now work for the div. protocols on native types like that can be icky

colinkahn20:11:23

Calling (p/datafy ...) directly does, so that's why it's odd to me

colinkahn21:11:12

Oh interesting, 

(satisfies? p/Datafiable (js/Error. "oops")) ;; true

 (tap> (js/Error. "oops"))
This does work, so it is datafying somethings

colinkahn21:11:36

ah and this works too: 

(deftype Foo [x])

 (extend-type Foo
   p/Datafiable
   (datafy [this]
     {:x (.-x this)}))

 (tap> (Foo. :a))
So it's something w/ native types and then also metadata protocols?

thheller21:11:06

there was a problem around metadata protocols, I'm not actually sure the fix for this is in yet

thheller21:11:17

hmm yeah seems to be in

colinkahn21:11:14

Well, both of those examples at the top work in the REPL w/ direct calls to p/datafy, just something about the Inspect UI not recognizing them to datafy

thheller21:11:43

hmm yeah I'm not entirely sure

thheller21:11:11

too tired to check. IIRC everything gets datafied as the very first step, but maybe I misremember

colinkahn21:11:43

No worries. I can make an issue for it. It'd be nice to have parity with tools like REBL.