This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-09-08
Channels
- # architecture (8)
- # aws (25)
- # babashka (9)
- # beginners (57)
- # calva (16)
- # cider (16)
- # clj-kondo (3)
- # cljdoc (13)
- # cljsrn (6)
- # clojure (272)
- # clojure-europe (36)
- # clojure-losangeles (1)
- # clojure-nl (8)
- # clojure-poland (3)
- # clojure-spec (4)
- # clojure-uk (8)
- # clojuredesign-podcast (9)
- # clojurescript (92)
- # code-reviews (1)
- # conjure (8)
- # core-async (1)
- # cursive (13)
- # datalog (1)
- # datascript (35)
- # datomic (76)
- # duct (10)
- # emacs (5)
- # events (7)
- # figwheel-main (1)
- # fulcro (35)
- # graalvm (20)
- # graphql (6)
- # jobs (3)
- # klipse (1)
- # london-clojurians (1)
- # malli (3)
- # off-topic (223)
- # pathom (2)
- # pedestal (13)
- # portal (1)
- # reitit (6)
- # remote-jobs (1)
- # shadow-cljs (21)
- # specter (2)
- # sql (63)
- # tools-deps (85)
- # tree-sitter (4)
- # xtdb (6)
This seems to be what you were talking about. I really have no idea where to go from here... but I'd love to figure it out as I'm very close with this Storybook/ClojureScript library.
Is it better to have a separate shadow-cljs build for devcards, or a single build for the app with devcards as a module?
@rickmoynihan always separate build. :modules
are not meant for this.
@thheller: Yeah, I’m reviewing a PR from a colleague — I was expecting a separate build. Why is it better to do a separate build rather than as modules though? Will it result in devcards being compiled into the prod app?
So what do modules actually do? Our setup essentially looks like this:
:main {:entries [app.main]
:init-fn mut.main/pre-init}
:cards {:entries [app.dev.cards]
:depends-on #{:main}}
From a human perspective, obviously they essentially give us separate exposed entry points into the app i.e. init fns.The userguide says: > When using multiple Modules the code is split so that the maximum amount of code is moved to the outer edges of the graph. But I’m not quite sure what that means, and how it would differ from two builds.
and that means that any code that is kept alive that couldn't be moved will make the :main
module larger than it needs to be
ahh ok so a codepath from :cards
might mean it can’t dead code eliminate something it otherwise would be able to
if you are very careful you can do it ... but its just not worth doing over a secondary build
yeah — seems like it mixes concerns to me… i.e each build already has a dev and prod env; and here we’re kinda saying devcards is a prod dependency, and relying on dead-code elimination / module-shuffling to figure it out
where as we could just tell it; and guarantee it’ll never make it in; and make the intent clearer.
Can you associate tools-deps aliases with a specific build?
I want to theme some Semantic UI, which afaik involves compiling less files. What’s the easiest way to introduce that into a shadow-cljs project?