Fork me on GitHub

is this object notation allowed in shadow? ( cljs docs says its supported (, but not sure why i'm receiving use of unresolved var


specifically the require looks like this [lib.core :refer [comp]] and i'm trying to use it like this (comp.view (comp.text "Hello World"))


that is not valid syntax no


it is not valid for refer etc. pretty much only for global symbols


i'm looking at adding a bit more support to clojure-lsp for shadow. The base for this is knowing the classpath for a project. I see that you can run shadow-cljs classpath and get the classpath but it unfortunately prints out some info that is unnecessary like config, node version, etc. Is there a way to get just the classpath info without any of this extra information?


@dpsutton the "extra" info is printed to stderr. the classpath info should be the only thing on stdout


awesome. thanks


indeed. thanks!


I’m coming back to clojure and CLJS after a hiatus, and I’m curious how shadow-cljs compares to figwheel-main. Last I checked, shadow-cljs was superior for integrating nodejs libraries.


shadow-cljs still does way more than figwheel and still has better npm interop 😉


@dpsutton on a slightly related note, if invoking shadow-cljs via npx or yarn, those have flags to be more quiet in the output. for npx it's --quiet and for yarn it's --silent.


are you saying that npx shadow-cljs classpath will put the stderr onto std out?


i also used shadow-cljs classpath in a project and found that without the --quite and/or --silent flags was seeing extra output (if using yarn/npx). at least that was my recollection. i don't recall exactly what happens without them, but i found that using the flags seemed to help 🙂


npx --help says:

--quiet, -q            Suppress output from npx itself. Subcommands will not
                         be affected.                                  [boolean]


Awesome. Thanks for the pointer. I bet that’s truly awful to figure out in the wild :)


lol, wasn't fun for sure 🙂


@thheller Ah, ok. It’s nice to be back. 🙂 What about rebel readline? I guess that doesn’t matter with cider, correct? Do you have feature list for comparison? I’m sure you hear this question all the time


I can't do comparisons since I have never used figwheel or figwheel-main. rebel-readline is not supported but that doesn't matter with cider. cider has good support for shadow-cljs nowadays (I think, I use Cursive)


it does 🙂 rebel readline is a terminal client and not necessary if you are using an integrated editor


So really, then, is there any reason I’d use figwheel-main? 😉


Not for me 🙂


Seriously, Shqadow does integrate better with any target I've tried. It is better on generating node (I'm using it currently on some devops projects and did some experiments with proton-native), node libraries (Chlorine is one of these, I also made a hubot script with it), browser (it can live-reload jQuery 😄) and so on


I have a side question, as well. I recently spoke with a CTO who says the Google Closure compiler is really not that great. That’s the first time I’d ever heard that, and he’s been working with CLJS for quite some time. Have you found that to be the case? Just curious.


I’d been singing praises of Closure over the usual (more common) JS ecosystem, but I don’t want to repeat misinformation.


it would be interesting to hear more specifics regarding "really not that great" 🙂


Yes, I wish I had more to offer, but it was a brief conversation.


it is "not that great" if you point it at random javascript from npm


if you use it with code that is written for it (CLJS, Closure Library) it is absolutely fantastic with nothing else coming even remotely close in the JS world currently


has anyone seen this error before? I get it when i do shadow-cljs release app


I am trying to add the following as a dependency in my shadow-cljs.edn file and I get “bad artifact coordinates” error - obviously bad formatting:

[metosin/malli {:git/url ""
               :sha     "1a1038d2473c6de784252b6ad42a6cc1e764ebcc"}]
How do I do this?


@slack1490 that is caused by a dependency conflict. likely because you are using deps.edn or project.clj. you should have these versions

[ "v20191027"]

   [org.clojure/google-closure-library "0.0-20191016-6ae1f72f"]
   [org.clojure/google-closure-library-third-party "0.0-20191016-6ae1f72f"]


thanks! I'll look into it


awesome, got it going. thanks again

👍 4

@tbrooke git deps are only supported if you manage dependencies via deps.edn. shadow-cljs.edn does not currently support them directly.


Some people expressed interest in the web framework I'm working on. I wrote down some notes and started porting the shadow-cljs UI in case anyone is still interested. finally no more react 🙂

👍 36

Wow, great! How does it compare, for example, with reagent/react/vue? Does it uses some kind of "virtual DOM", does it listens to changes on atoms?


there is no full virtual DOM no. it can listen to changes on atoms yes


I'll write more about this if I decide to make this an actual framework at some point 😛


nowhere near ready for public use but I can setup a basic example app if someone feels like experimenting


the next shadow-cljs release will include UI built on top of it so you'll see it in action there 😉