this patch is sufficient to fix the test and make everything succeed… what I find strange is that the field CLJS is attempting to set has been private for over a year… so why would it pass in the may version but not the august version??

shadow-cljs does not use the cljs.closure namespace, so we might be fine

cljs itself is probably still depending on a much older version?

[com.google.javascript/closure-compiler-unshaded "v20220502"]

but even that I think is unreleased

good catch, i didn't read the year correctly. given what you've said about shadow-cljs not using cljs.closure, then all that is left is to test shadow-cljs itself

is there a way to choose aliases per build, and per release/dev?

no

Can you use a symlink into node_modules ?

the library depended on is in our own control as well by the way

preferably the interface is such that we only add that library in our project.clj and the resources are shared, but can imagine this is blocked for security reasons or so

maybe by adding something like

:resource-paths ["src/resources" "path/to/library/resources"] 

if this is a clojure library you can just keep the files in the jar

no copying needed

:dev-http {8080 "classpath:public"} will find things in the jar

thanks! and for a release build?

uhm I assume you have a server of some kind?

otherwise yes, you need to copy things out

yes nginx just serves

ah ok, I assumed some kind of clj server

ah okay so for that i do need a build step

yes

thanks!

I do not recommend a build hook though

I guess my question is why is this in .clojure/deps.edn?

Plugging in random dev tooling from outside the project

is it your project? or can you change the project?

it’s mine, yes

the current approach is to keep the tooling strictly out of the main project. If that’s impossible, I’ll consider alternatives

that doesn't match what you asked earlier about replacing :preloads?

the answer is that there is currently no way to replace this

there’s one preload that is currently pre-configured in shadow-cljs.edn.

doesn't mean there can't be but I want to understand the use case before considering anything

So to be more specific and concrete, we have: 1. A preload for a dev tool in the project 2. Per-dev tooling that require preloads. Some require a certain order relative to the pre-configured one

that order you can establish by having the namespace itself require the other

(ns foo.preload2 (:require [foo.preload1])) even with :preloads [foo.preload2 foo.preload1] this ensures that 1 loads before 2

yeah, but since all of these except the pre-configured one are optional, they can’t really require each other

I’ll think about this, there may be an angle in the require idea

I could also add all tooling as aliases in project deps.edn. There’s still the issue of how to compose the preloads in config-merge

can you specify what these preloads do in the first place? I guess I don't quite get what they do

or have a script that launches shadow, and solve this on the CLI by having the default watch startup provide --config-merge {:preloads [default-preload]}

• Malli function instrumentation init • Malli clj-kondo config generation watcher • Flow-storm debugger • Hashp logging tool Where Flow-storm is optional, and has to be first if it’s included

I guess you could use a build hook. thats just CLJ code that can do pretty much anything

We have a script that sets up parameters for shadow-cljs, I managed to fix it there by specifying aliases and preloads, with defaults. That does what we need. Thanks a lot for talking through this with me!

the :flow-storm alias has the flow-storm code, but I do not want the flowstorm code in the release build.

the problem I'm encountering is that when run via cider, the only aliases that seem to be respected are the ones used in the top level :deps -> :aliases path

you are looking at the wrong piece of configuration

the only thing that controls what ends up in your build is your code and build config

thus if you require any flowstorm related code in your namespaces it will be part of your build

same when putting it in your build config, besides :preloads

deps.edn or aliases are not relevant to this in any way as a required namespace is always required and not optional

:preloads btw are only applied to watch/compile builds, not release

so you can just leave it in the config for release builds, it won't affect the build

you can verify the structure of your build via build reports

https://shadow-cljs.github.io/docs/UsersGuide.html#build-report

if you mouse over a file/namespace line it'll also tell you why it was in included

Ok -- but my question was how can you selectively include aliases

shadow-cljs does not support this since it breaks server mode

you can launch via clj directly, and nothing is stopping you from using whatever aliases there

so clj -A:whatever:aliases:you:like -M -m shadow.cljs.devtools.cli release app

I'd recommend using your development aliases by default in shadow-cljs and running via clj directly for release builds

Unless we can change deps on a per build basis, I'd need two different shadow-cljs files

as I just explained. you can do whatever you want when running with CLJ directly. shadow-cljs itself does not and will not support defining per build aliases

Ok, great 🙂 Does it support different shadow-cljs files? clj -A:whatever doesn't play as nicely with CIDER for me

if not I'll work around it

there is only one shadow-cljs.edn, not changable

Ok, thanks 🙂