This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-22
Channels
- # aws (4)
- # bangalore-clj (2)
- # beginners (99)
- # boot (8)
- # clojars (22)
- # clojure (87)
- # clojure-dev (2)
- # clojure-greece (10)
- # clojure-russia (22)
- # clojurescript (80)
- # cursive (4)
- # data-science (2)
- # datomic (10)
- # emacs (1)
- # fulcro (1)
- # garden (2)
- # luminus (1)
- # lumo (29)
- # off-topic (20)
- # om (6)
- # onyx (18)
- # parinfer (7)
- # perun (1)
- # portkey (28)
- # re-frame (93)
- # reagent (59)
- # ring-swagger (2)
- # shadow-cljs (31)
- # slack-help (15)
- # spacemacs (5)
- # uncomplicate (3)
- # yada (6)
@thheller hah good timing, someone in #re-frame today was trying to get re-frame-trace to work with shadow-cljs. I posted an explanation of what we figured out yesterday: https://clojurians.slack.com/archives/C073DKH9P/p1508662534000031 feel free to correct/suggest alternatives
:failed-to-compare "github:braintripping/Keypress#4477249" "github:braintripping/Keypress#4477249" #error {
:cause "TypeError: Invalid SemVer Range: github:braintripping/Keypress#4477249"
@mhuebert one thing I noticed in the re-frame thing :closure-defines {re-frame.trace.trace-enabled? true}
@thheller i don't thing you've seen it, but in lumo we were thinking about deploying Cljs to npm and how to put info in package.json
. I think we are on the brink of needing it anyways š
@richiardiandrea not sure I understand the intent here. why would we āneedā it?
How do you load clj in shadow-cljs now? From maven?
So that would allow to consume them from npm
So companies don't have to have two mirrors, one for maven, one for npm
If they work with ClojureScript
problem with introducing a new package manager is that you will end up having packages that are only available in one
having CLJS packages declaring :npm-deps
is already complicated, the reverse would make it even more complicated
Gotcha, yeah, it will go the way you described anyways, because it is not feasible to do both, so Clojure package maintainers will eventually choose. Our tooling did not make the choice that other *Script languages have taken (use npm) so we carry this burden with us now.
publish to npm is not a problem per se, as long as you keep JVM semantics (ie. classpath and namespaces)