This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-11-16
Channels
- # announcements (7)
- # babashka (8)
- # beginners (48)
- # calva (4)
- # cider (6)
- # circleci (2)
- # clj-commons (14)
- # clj-kondo (3)
- # clj-on-windows (7)
- # cljs-dev (34)
- # clojure (49)
- # clojure-dev (25)
- # clojure-europe (48)
- # clojure-losangeles (1)
- # clojure-nl (4)
- # clojure-norway (33)
- # clojure-uk (2)
- # clojurescript (37)
- # community-development (5)
- # conjure (17)
- # cursive (2)
- # data-science (1)
- # editors (10)
- # emacs (50)
- # events (22)
- # honeysql (11)
- # introduce-yourself (1)
- # jobs-discuss (13)
- # lsp (42)
- # malli (9)
- # off-topic (7)
- # pathom (11)
- # portal (5)
- # re-frame (3)
- # reagent (22)
- # reitit (8)
- # reveal (1)
- # rewrite-clj (4)
- # shadow-cljs (38)
- # xtdb (21)
@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?
oh wait I guess I just read that wrong. you use one for everything, with only one package.json total?
Can I specity per-build deps.edn aliases?
Because I got two app.client
in different paths for two different builds. In src/website
and src/launcher
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
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
I kinda don’t want that
but I could
shadow-cljs watch website
is the same as clj -A:whatever:aliases -M -m shadow.cljs.devtools.cli watch website
Are those problems documented somewhere?
aliases control the classpath. the JVM can only have one classpath. so any changes to the classpath require starting a new jvm
thus you will have 2 independent instances if you want two builds to run and the same time
they are going to compete and interfere with each other since shadow-cljs is not designed for this
ok, I see
I will follow your initial suggestion, then
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
you can still easily move the stuff that those namespaces share into a shared namespace and keep the relevant specific parts in each
Yeah, I guess that works as well
Are there any known issues with the Inspect
feature of shadow-cljs UI not datafying?
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).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
Oh interesting,
(satisfies? p/Datafiable (js/Error. "oops")) ;; true
(tap> (js/Error. "oops"))
This does work, so it is datafying somethingsah 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?there was a problem around metadata protocols, I'm not actually sure the fix for this is in yet
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