shadow-cljs

https://github.com/thheller/shadow-cljs | https://github.com/sponsors/thheller | https://www.patreon.com/thheller
neilyio 2020-09-08T00:01:31.186400Z

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.

2020-09-08T09:43:06.187600Z

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

thheller 2020-09-08T09:49:36.188800Z

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

2020-09-08T09:51:12.190200Z

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

thheller 2020-09-08T09:52:18.190700Z

basically yes

2020-09-08T10:01:17.192600Z

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.

2020-09-08T10:02:29.193800Z

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.

thheller 2020-09-08T10:03:27.195200Z

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

thheller 2020-09-08T10:03:39.195700Z

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

thheller 2020-09-08T10:03:49.196100Z

BUT a regular user will never load the cards

2020-09-08T10:03:57.196600Z

yes

thheller 2020-09-08T10:04:08.196900Z

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

2020-09-08T10:05:21.198500Z

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

thheller 2020-09-08T10:05:29.199Z

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

thheller 2020-09-08T10:05:58.199700Z

yes, it negatively impacts DCE in almost all cases

2020-09-08T10:06:39.200500Z

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

2020-09-08T10:07:22.201100Z

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

thheller 2020-09-08T10:09:23.201900Z

yep

2020-09-08T14:17:31.203200Z

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

thheller 2020-09-08T15:39:32.203500Z

no

roklenarcic 2020-09-08T18:51:39.203800Z

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?