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 😉

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"}}}

@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"}}}
...

:deps {:aliases [:shadow :dev :cljs-flowstorm]}

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

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!

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-cljs • shadow-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.

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.

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

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?

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?

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

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.

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

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": [
            ":app",
        ],
        "cljAliases": [
            ":dev",
            ":shadow",
            ":flow"
        ],
        "cljsDefaultBuild": ":app"
    }
}