I have no idea if that's related, but I remember having the same problem when I used Atom in the past (without Shadow) and I did solve by adding :output-wrapper true. Shadow's documentation says that this option is only relevant for the browser target, and I did try to add it in my config, and it didn't change the output; I also found that Shadow generates a var shadow$provide = {}; in the top-level; again, not sure if it's relevant...

it is not supported to have two builds in the same context

well, I guess it depends on the target? :target :esm should be fine

:target :browser or whatever else that lives in the global scope will be a problem as some "glue" code such as shadow$provide needs to be global

So it seems that multiple release builds with pseudo-names are conflicting with each other? Is that possible?

in :node-library no. assuming its actually getting loaded in node of course?

there is also no shadow$provide in node builds? or do you use :js-provider :shadow?

or are you trying to pass one CLJS object from one build to another? that'll not work since they are different "types"

Yes, I'm using :js-provider :shadow

(and no, I'm not trying to pass one CLJS object from one build to another, it's just two builds that use promesa in different versions that are somehow conflicting with each other because both extend the Promise Javascript object)

well since its extending the js Promise type the protocol might override each other I guess

guaranteed by the pseudo-names, since that ensures its the same protocol property

and in cljs things use the cljs.core/PROTOCOL-SENTINEL to verify that something actually implements the protocol. since that will be different objects for each build, they basically overwrite each other

That makes a lot of sense, thanks for the help!

Never though about the implications of pseudo-names, good to know

well it could totally happen for regular :advanced code too

will definitely happen for :simple