Fork me on GitHub

Is there a way to configure shadow-cljs so that I can use deps.edn with different aliases depending on build? I want to include a :dev alias only in development, and not when building a release build.


this is not necessary. having extra stuff on the classpath doesn't matter. the build decides what is used, not the classpath


so unless you specifically require something it won't be included in the build


and no, there is no support for build specific aliases because of that


Sounds great. Thanks!


as always you should verify what ends up in your builds with a build report 😉

Dallas Surewood14:07:06

There are cases where having support for build specific aliases would be nice. For instance, @U0739PUFQ recommends using ClojureStorm when using his flow-storm library. It involves overriding the default Clojure compiler with his.

:flow {:classpath-overrides {org.clojure/clojure nil}
                  :extra-deps {com.github.jpmonettas/clojure {:mvn/version "RELEASE"}
                               com.github.jpmonettas/flow-storm-dbg {:mvn/version "RELEASE"}}}
So when my shadow-cljs looks like this :deps {:aliases [:shadow :dev :flow]} That means production builds are using the ClojureStorm compiler, regardless of what you're requiring. You'd need to remove :flow every time you build for prod.


@U042LKM3WCW you don't need to add the :flow alias there, since ClojureStorm is only a Clojure thing, so on shadow-cljs.edn you probably only want things that are ClojureScript related. I think what you want is this : deps.edn aliases

:clj-flowstorm {:classpath-overrides {org.clojure/clojure nil}
               :extra-deps {com.github.jpmonettas/clojure {:mvn/version "1.11.1-8"}
                            com.github.jpmonettas/flow-storm-dbg {:mvn/version "3.6.10"}}}
:cljs-flowstorm {:extra-deps {com.github.jpmonettas/flow-storm-inst {:mvn/version "3.6.10"}}}
so then on your shadow-cljs.edn you can have like :
:deps {:aliases [:shadow :dev :cljs-flowstorm]}
does it make sense?


Another option you have (the one I use) is instead of adding that :cljs-flowstorm alias there, run your shadow watch like this :

npx shadow-cljs -d com.github.jpmonettas/flow-storm-inst:3.6.10 watch :your-app-build-id
I normally have that in the project folder inside a script called watch-cljs


with that, flow-storm will only be available for watching for you, and you don't even need to modify any shadow-cljs.edn


so with shadow-cljs -d and together with local aliases (on your ~/.clojure) you can setup flow-storm for Clojure and ClojureScript without even modifying project files (in case people don't want to pollute it with dev tooling)


you can also just run clj -A:release:aliases -M -m shadow.cljs.devtools.cli release app to use different aliases for release builds


if you really need different aliases then thats the way to go, the shadow-cljs command is not needed


many options!

Dallas Surewood18:07:03

Absorbing all of this. To clarify, the reason I had non cljs stuff in the aliases is because Calva has a convenient jack-in command that sets up all the REPLs for you. But there are two options • deps.edn + shadow-cljsshadow-cljs If you pick the first, your cljs output goes to the terminal and not the REPL. If you pick the second, you're running the whole app with shadow-cljs and you won't be able to evaluate clj code. It's nice to go into any file and not think about whether it's cljs and clj and just evaluate it. So they originally recommended adding CLJ aliases, and that's why Pez was asking about this a year ago


using different aliases requires starting a fresh new JVM and therefore REPL. I'm pretty sure that is not what he asked about


where output goes seems like a calva issue? shadow-cljs sends it to the same place and has no special "output goes here for calva"?


Picking shadow-cljs doesn’t mean you can’t evaluate clj things? Did I misunderstand you about this, @U042LKM3WCW?


> where output goes seems like a calva issue? shadow-cljs sends it to the same place and has no special "output goes here for calva"? If you let shadow start the clojure, shadow’s output stays in the terminal process. If the Clojure app starts shadow, shadow output goes to the repl. I guess that’s just the way it is.


Personally, I prefer keeping shadow’s output in the terminal.

Dallas Surewood18:07:57

Not that you can't evaluate clj files, but none of those will be in your source paths. If I just used a cljs alias in in my shadow-cljs.edn, (say :shadow) it will crash when trying to evaluate clj files with dependencies outside of the :shadow alias. So I'm not sure how it's possible to run without including other aliases.


Iiuc, giving shadow-cljs -A options, will cause it to override the :aliases vector in the config?


not override, add.

👍 2

And you can make Calva provide the -A option by specifying cljAliases in a connect sequence configuration.

Dallas Surewood18:07:20

Okay, so you're thinking add -A when in dev with a sequence configuration and then just have a release build when I'm ready?


Yes, but I’m not sure it’s enough for your use case?

👍 2
Dallas Surewood18:07:30

I'm sure one of these is enough, thank you all. It's slight overload because I feel like I have a 70% grasp on some of these suggestions or how they solve the problem.


I’m afk right now, so can’t really help experiment. But if you use a connect sequence for development and add whatever release aliases you need with -A too, and keep only the common aliases in the config, maybe that could work?

Dallas Surewood18:07:37

Np I was playing with that earlier so I think it will work

Dallas Surewood18:07:58

Or I'll try another option, thank you


We have recently fixed bugs with cljAliases so it might be that it didn’t work last time you tried, but now it should work.

Dallas Surewood18:07:57

That could be true, this is an old project I just poke at in my off time. Things might be setup weird.

Dallas Surewood19:07:29

That seemed to work great. Thanks for your help. I will try the other options too for fun later. This was my launch option

    "name": "backend + frontend",
    "projectType": "shadow-cljs",
    "cljsType": "shadow-cljs",
    "menuSelections": {
        "cljsLaunchBuilds": [
        "cljAliases": [
        "cljsDefaultBuild": ":app"

🙏 2

Hi, I'm a beginner and I'm trying to use react-spline ( in a new Reagent app. But when I import it like this: ["@splinetool/react-spline" :as Spline] I get the attached error. Any ideas what causes this?


@dev900 dunno what that is. I can reproduce it though. It is an error in the Closure Compiler though, so not much I can do about that from the shadow-cljs side of things


@thheller thanks so much for checking 🙂 That's unfortunate. I guess I'm going back to Nextjs for this project 😢


that probably doesn't have that issue