clojurescript

Ryan 2025-07-21T17:14:13.458129Z

Anyone have any best practices on conditionally including source files at build time? We pass in an instance type, and we would like to load a src file based on that instance type, like for two instance types ["car" "boat"] if we are building a car-type, we'd like data.config.car to be loaded, conversely data.config.boat.. right now they live in a big map where the top-most key is the instance type, but we'd like to break them out to shake the bundle size, because the config maps can get pretty large. Any clues appreciated 🙂 Sorry if its not nearly enough specifics, can try and be more specific if needed. edit: current build is via babashka -> shadow-cljs

p-himik 2025-07-21T17:17:25.150699Z

> We pass in an instance type Pass to what? And how? Is that information available at compile time, with a guarantee that a new instance type won't appear?

Ryan 2025-07-21T17:21:25.598379Z

We pass the instance type to babashka like: bb run-local --instance-type "car" --stage "dev" this does a few things, including putting the instance type and stage as header metadata in the index, from whence its scooped up by re-frame on load and stored in app-db.. the config is 100% available at compile time and no need for it to mutate once built,

p-himik 2025-07-21T17:23:46.544029Z

I'd do it via separate shadow-cljs builds then. You can also do all the other mentioned stuff that way, too. Just have some :closure-defines in each build and use those values in the initial value of app-db.

👍 1
Ryan 2025-07-21T17:25:32.963709Z

Thanks! I was looking at the build targets but wasn't sure if that was the right feature to pint this on

p-himik 2025-07-21T17:26:11.647919Z

No-no, not build targets. Just builds. (Just in case.)

😅 1
Ryan 2025-07-21T17:28:33.037449Z

Oh good catch, I had conflated the two in my head since out of the box there's basically 1 build in there per type, but yes, Just builds!

thheller 2025-07-21T18:16:24.762589Z

if its just data I'd load them as .edn files and not compile them at all

thheller 2025-07-21T18:17:23.611749Z

otherwise you could do code splitting and use a module per "type" https://code.thheller.com/blog/shadow-cljs/2019/03/03/code-splitting-clojurescript.html

🙏 1
thheller 2025-07-21T18:18:15.633389Z

alternatively multiple builds is also fine, if its all completely static

schadocalex 2025-07-21T19:37:57.526339Z

We have a similar usecase and we use the compiler option :reader-features. With a common cljc file we require/register functions in specific namespaces with that. Flexible, managed by Clojure itself so it does not rely on later optimization, and we also didn't want to separate the code in different builds (for few reasons). Note that we use the shadow cljs CLI with the --config-merge to dynamically set this (and it's not necessarly one reader-macro for each instance).

👍 1