Fork me on GitHub
#shadow-cljs
<
2020-09-08
>
neilyio00:09:31

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.

rickmoynihan09:09:06

Is it better to have a separate shadow-cljs build for devcards, or a single build for the app with devcards as a module?

thheller09:09:36

@rickmoynihan always separate build. :modules are not meant for this.

rickmoynihan09:09:12

@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?

thheller09:09:18

basically yes

rickmoynihan10:09:17

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.

rickmoynihan10:09:29

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.

thheller10:09:27

it means exactly that. don't know how to describe it differently 😞

thheller10:09:39

basically the cards module will contain all the code of the cards in theory

thheller10:09:49

BUT a regular user will never load the cards

thheller10:09:08

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

rickmoynihan10:09:21

ahh ok so a codepath from :cards might mean it can’t dead code eliminate something it otherwise would be able to

thheller10:09:29

if you are very careful you can do it ... but its just not worth doing over a secondary build

thheller10:09:58

yes, it negatively impacts DCE in almost all cases

rickmoynihan10:09:39

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

rickmoynihan10:09:22

where as we could just tell it; and guarantee it’ll never make it in; and make the intent clearer.

rickmoynihan14:09:31

Can you associate tools-deps aliases with a specific build?

roklenarcic18:09:39

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?