This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-05
Channels
- # announcements (7)
- # beginners (107)
- # boot (5)
- # calva (2)
- # cider (18)
- # clj-kondo (48)
- # cljs-dev (16)
- # cljsrn (2)
- # clojure (208)
- # clojure-berlin (1)
- # clojure-dev (25)
- # clojure-europe (14)
- # clojure-italy (10)
- # clojure-nl (10)
- # clojure-sg (1)
- # clojure-spec (52)
- # clojure-uk (13)
- # clojurescript (53)
- # cursive (7)
- # data-science (7)
- # datomic (4)
- # duct (1)
- # events (10)
- # fulcro (1)
- # graphql (5)
- # jobs (2)
- # kaocha (13)
- # leiningen (6)
- # off-topic (17)
- # pathom (4)
- # quil (6)
- # re-frame (52)
- # reagent (12)
- # reitit (3)
- # shadow-cljs (97)
- # spacemacs (10)
- # sql (39)
- # tools-deps (18)
- # uncomplicate (1)
- # xtdb (1)
If I’m starting a new project, should I choose Shadow-cljs over Figwheel-main? Is Shadow-cljs going to be a replacement for Figwheel or does it target a different use case, like better npm-integration and targeting Node and React native platforms?
For what it’s worth, if you want to use NPM dependencies, shadow-cljs makes it really easy.
That’s a really big selling point
I feel that’s the wrong question. The question is: Do you want to use shadow-cljs or the vanilla cljs.main as your compiler for the project? If you choose cljs.main (the ClojureScript compiler), then using figwheel for your auto-building while developing is cool.
Thanks Danie. Is there a comparison somewhere between the two compilers? I was listening The REPL -podcasts where Heller was talking about shadow-cljs and compiling process but most of that stuff went over my head 🙂
(to be more correct: To only use cljs.main, since shadow obviously leverages it) - https://code.thheller.com/blog/shadow-cljs/2019/03/01/what-shadow-cljs-is-and-isnt.html
If you are choosing cljs.main, then https://clojurescript.org/guides/webpack is how you would be adding npm packages
figwheel is harder to set up, (at least that was my experience). as soon as someone here recommended shadow-cljs to me, i was set up and ready to go, and i dont see any weak points ;D
That’s good to know. I was working previously in a project where the Figwheel was setup before I joined it, so I didn’t get experience about that part
Thanks Danie. Is there a comparison somewhere between the two compilers? I was listening The REPL -podcasts where Heller was talking about shadow-cljs and compiling process but most of that stuff went over my head 🙂
there's only one compiler - ClojureScript - it does have basic build tool facilities as that's fundamentally necessary
Thanks David. Maybe I should just take both of them for a ride and see how they compare in practice 🛠️
I don't personally think anything but ClojureScript + Figwheel for REPL niceties is really necessary to be productive and to ship software. shadow-cljs is more of a complete package and that's nice.
How does one use core.async in a CLJS macro? The macro is written in CLJ but needs to output CLJS code. So I'm confused by what the require form should look like. In CLJ it would be something like (:require [clojure.core.async :refer [chan]])
but needs to output code that refers to cljs.core.async
. I feel like I'm missing something simple, but it's not clicking.
just (:require [clojure.core.async :as async])
and use (async/go (async/<! (async/chan)))
...
Hmm... I stumbled onto (:require [cljs.core.async])
and just using fully-qualified names in a CLJC file. That seems to work, but I was hoping to find a way to make :refer
work. Oh well, not a big deal.
@cap10morgan it's not actually simple
right, hence my confusion 🙂
means you need to explicit - so writing macros in ClojureScript really isn't quite as easy
Is there a straightforward and/or reliable way to require a clojurescript module from npm? I know the reverse is trivial. I would like to avoid the need to commit build artifacts
Perhaps the "prepare" npm script is the right way to go about committing build artifacts if that's unavoidable
Have a need for using cljs for state management, packaged for use by js devs across agency lines who don't have cljs build tools or experience. I think I'm going to go with the npm option as a standardized way to go about building and checking in. Thanks for bringing up lumo though, that could be useful
@dougkrieger you're likely to run into issues w/ that
@dougkrieger it really depends on whether you want to distribute multiple artifacts - if the answer is no, you can probably make it work w/o much hassle
Anyone seen this before?
# cljsbuild once prod
Compiling ClojureScript...
Unrecognized option: -J-Xmx750M
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Subprocess failed
And out of nowhere, the problem is back.
@skuttleman looks like you are passing a deps.edn style JVM arg via lein
?
There are no :jvm-opts
declared in project.clj
.
I took an alternate path of nuking from orbit and re-cloning. Working now. No clue how it broke.