Fork me on GitHub
Tiago Dall'Oca12:06:26

                return evalCheck('let r;try{r\x3d", "}catch{};r'););

    SyntaxError: Unexpected token ')'

    > 1 | var $CLJS = require("./cljs_env");
        |             ^
      2 | var $jscomp = $CLJS.$jscomp;
      3 | var COMPILED = false;
      4 | require("./cljs.core.js");

      at Runtime.createScriptFromCode (../../node_modules/.pnpm/[email protected]/node_modules/jest-runtime/build/index.js:1728:14)
      at Object.<anonymous> (.../dist/mn.flow.ibanxs_data.js:1:13)

Tiago Dall'Oca12:06:02

disclaimer: omitted some of the sensible dirs

Tiago Dall'Oca12:06:36

when trying to run a compiled cljs with :target :npm-module on jest, I get this

Tiago Dall'Oca12:06:29

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

Tiago Dall'Oca12:06:06

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')
> validate(typeSchemas.Country, { id: "BR", name: "Brazil" })
> validate(typeSchemas.Country, { id: "BR", name: 123 })

Tiago Dall'Oca14:06:40

not really related to shadow-cljs, but with jest

Tiago Dall'Oca14:06:20

needed to use transformIgnorePatterns option on jest's config to ignore compiled cljs files

Tiago Dall'Oca19:06:12

when attempting to load two different :npm-modules in the same js file, I get this

Namespace "goog.debug.Error" already declared.

      107 |   if (!COMPILED) {
      108 |     if (goog.isProvided_(name)) {
    > 109 |       throw new Error('Namespace "' + name + '" already declared.');
          |             ^
      110 |     }
      111 |     delete goog.implicitNamespaces_[name];
      112 |   }

Tiago Dall'Oca19:06:27

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

Tiago Dall'Oca19:06:30

they are two different "libraries"


makes no sense to do that really


thats fine. just have one build thats includes the two

Tiago Dall'Oca19:06:09

defined in two different shadow-cljs.edn

Tiago Dall'Oca19:06:47

the idea would be to have reusable npm-like libraries

Tiago Dall'Oca19:06:59

that could be required as needed

Tiago Dall'Oca19:06:37

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


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

Tiago Dall'Oca19:06:41

I thought about it

Tiago Dall'Oca19:06:57

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)

Tiago Dall'Oca19:06:22

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


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

Tiago Dall'Oca19:06:20

let me see if I understood


that is just not something that is feasible in CLJS

Tiago Dall'Oca19:06:05

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


please expand on what you are actually trying to do


maybe I can explain it better in that context

Tiago Dall'Oca19:06:45

I'm trying to integrate cljs in js

Tiago Dall'Oca19:06:53

legacy ts code that is

Tiago Dall'Oca19:06:22

we work with multiple packages


so you have two separate CLJS libraries

Tiago Dall'Oca19:06:42

each package acting as its own standalone lib


that you want to include in that ts code

Tiago Dall'Oca19:06:48

> so you have two separate CLJS libraries


ok. so you make a third "inclusion" library


that lib is actually compiled and includes both other libs


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

Tiago Dall'Oca19:06:01

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


that lib you consume in the TS code


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

Tiago Dall'Oca19:06:40

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


yes, they are actual CLJS libraries

Tiago Dall'Oca20:06:05

I think I got it now


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

Tiago Dall'Oca20:06:58

does deps.edn play well with shadow-cljs?


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

Tiago Dall'Oca12:06:09

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?

Tiago Dall'Oca12:06:38

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


no, you are treating this wrong


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

Tiago Dall'Oca17:06:01

> you literally only move I understood that

Tiago Dall'Oca17:06:36

just wasn't sure if server worked


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"

Tiago Dall'Oca17:06:37

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

Tiago Dall'Oca18:06:32

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

Tiago Dall'Oca18:06:12

after running shadow-cljs start

Tiago Dall'Oca18:06:36

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