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


I was curious if using dotted symbols (outside of js/) to access nested JavaScript object properties is correct or an abuse. A concrete example is (def x #js {:foo #js {:bar 17}}) followed by evaluating This was made to work with Similarly (let [y #js {:foo #js {:bar 17}}] works (I suppose we could find the code and or ticket justifying it as well). My takeaway is that perhaps this is legit, and should be documented in the JavaScript interop page as being equally valid to more verbose constructs like (.. x -foo -bar) On the other hand, I suspect that things like #' result in a working Var, may be simply an unintentional consequence.


@mfikes I think although undocumented nested dotted access is valid and would result in a great amount of breakage if removed


Would there be something equivalent to cljs.closure/find-cljs-dependencies that also includes macro namespaces? I’m trying to find a way to build a dependency graph that includes macros, without actually requiring everything into a compiler state.


I can currently build this graph by requiring everything into Planck or Lumo and then crawling the compiler state for transitive dependencies, but this is tricky because some namespaces don’t actually run in Planck/Lumo (they require a browser environment), so I had to stub out *eval-fn* with one that doesn’t throw on errors. It feels like there should be a more direct and fast way to figure this stuff out statically.


I made a recursive parse-ns fn in Lumo which seemed to work but was rather slow.


@mhuebert anything in particular you want to achieve? shadow-cljs has some functions that might help


@thheller still trying to get a better experience for bundling deps for the self-host compiler


I’ve had things ‘working’ for several months, but it’s a brittle pipeline, half Clojure script and half in Planck