disclaimer: omitted some of the sensible dirs

the same thing happens if run with :target :node-library

oh, and it works with node

Welcome to Node.js v14.19.3.
Type ".help" for more information.
> const { typeSchemas, validate, explain } = require('./dist/mn.flow.ibanxs_data.js')
undefined
> validate(typeSchemas.Country, { id: "BR", name: "Brazil" })
true
> validate(typeSchemas.Country, { id: "BR", name: 123 })
false

found it!

not really related to shadow-cljs, but with jest

it seems that runtime dependencies to run cljs is getting loaded twice

define two different :npm-module. you mean actual builds or separate namespaces?

as far as builds are concerned you should not do that and it is not supported

they are two different "libraries"

makes no sense to do that really

thats fine. just have one build thats includes the two

defined in two different shadow-cljs.edn

the idea would be to have reusable npm-like libraries

that could be required as needed

do you know what I mean?

yes, that is not a good idea and should not be done

each library will have its own cljs.core variant and they will not be compatible with each other

I see

not to forget the extra build size you get by having cljs.core twice

yes

I thought about it

is there a way to have cljs runtime dependencies loaded just once?

not in an :advanced optimized build (which is what you should aim for)

and btw, does this limits me to only being able to use monolith cljs libraries with node?

no you are missing what I'm saying

you can have ONE build that includes the whole universe of CLJS libraries. all of them for all I care.

via that one build you basically expose all of them to JS

the point is having one build so you only have each namespace once

right

the trouble only starts when you want to build pre-compiled libraries to be included in JS separately

let me see if I understood

that is just not something that is feasible in CLJS

having multiple cljs libs defined each with their own shadow-cljs.edn is a bad idea?

not feasible?

please expand on what you are actually trying to do

maybe I can explain it better in that context

right

I'm trying to integrate cljs in js

legacy ts code that is

ok

we work with multiple packages

so you have two separate CLJS libraries

each package acting as its own standalone lib

that you want to include in that ts code

> so you have two separate CLJS libraries

yes

ok. so you make a third "inclusion" library

that lib is actually compiled and includes both other libs

ok, right

they don't need to compiled at all on their own

you are doing that to avoid the duplication of cljs.core and other namespaces

but what if they those other 2 libs are defined in separate shadow-cljs.edn?

and to ensure the CLJS parts of the code are actually compatible with each other

they can have them. that is fine. that really doesn't matter here

you created a third lib that combines them

good

that lib you consume in the TS code

that is the only way to properly bridge CLJS code into JS/TS code

this third lib must have access to the cljs source of the original 2 libs, right?

yes, they are actual CLJS libraries

uhum

I think I got it now

if you use deps.edn you can just use :local/root or git urls

does deps.edn play well with shadow-cljs?

sure

just manages dependencies. does not affect compilation in any way if you use deps.edn or project.clj or just shadow-cljs.edn

ok

thanks a lot!

hey @U05224H0W, just confirm, if I'm using deps to manage my dependencies, do I have to use clj to compile or it still works running shadow-cljs?

also, server doesn't work with deps, right?

no, you are treating this wrong

https://shadow-cljs.github.io/docs/UsersGuide.html#deps-edn

you literally only move the :dependencies and :source-paths from shadow-cljs.edn to deps.edn (with :deps and :paths there) and add the thheller/shadow-cljs dependency which is automatically included in shadow-cljs.edn but not in deps.edn

everything else stays the same. you use the tool in the exact same way as before

you have the option of just using clj yes, but you do not need to

> you literally only move I understood that

just wasn't sure if server worked

with deps

again. it is just managing dependencies. the shadow-cljs CLI tool continues with the same functionality and nothing else changes

if you use clj instead of the shadow-cljs command then yes, server mode is limited

it still works but not in the same way as the shadow-cljs command

unless I'm misunderstanding by what you mean by "if server worked"

shadow-cljs start when :deps true

yes, that should work fine. never actually tried that myself though.

I only use shadow-cljs server. ie. start but keep running in foreground rather than background

shadow-cljs - config: .../shadow-cljs.edn
shadow-cljs - starting via "clojure"
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate shadow/cljs/devtools/cli__init.class, shadow/cljs/devtools/cli.clj or shadow/cljs/devtools/cli.cljc on classpath.

after running shadow-cljs start

even though I added shadow-cljs as :extra-deps

well did you set that alias in shadow-cljs.edn?

the above error you get when shadow-cljs is not on the classpath

so I assume you added it to some alias but did not set :deps {:aliases [:foo :bar]} accordingly