Fork me on GitHub
#shadow-cljs
<
2021-03-05
>
Cam Saul01:03:47

sorry if this is a dumb question, but I searched all over the place and couldn't find an answer to it. I have a small namespace I'm exporting as an :npm-module and using in JavaScript code... when I try to run our existing Jest unit tests for the JavaScript code, the JS file that's loading the the CLJS file is failing with

● Test suite failed to run

    Namespace "goog.math.Long" already declared.

      at Object.<anonymous>.goog.module (frontend/src/cljs/cljs_env.js:124:13)
      at frontend/src/cljs/goog.math.long.js:14:8
      at Object.<anonymous>.goog.loadModule (frontend/src/cljs/cljs_env.js:322:27)
      at Object.<anonymous> (frontend/src/cljs/goog.math.long.js:12:6)
      at Object.<anonymous> (frontend/src/cljs/cljs.core.js:4:1)
      at Object.<anonymous> (frontend/src/cljs/metabase.types.js:4:1)
      at Object.<anonymous> (frontend/src/metabase/lib/types.js:13:29)
Any idea what I might be doing wrong? I'm importing the CLJS code into the JS code like
import { isa, TYPE } from "cljs/metabase.types";
This works fine everywhere except for when I go to run the Jest unit tests

thheller07:03:10

@camsaul do you maybe have two different builds you are loading this way? or is there only one :npm-module build?

thheller07:03:24

that error you get when trying to load 2 separate CLJS builds into the same "global" context. they'll clash and interfere with each other so that really shouldn't be done

thheller07:03:37

could also just be Jest loading things in a strange way. not exactly sure how jest works.

thheller07:03:18

it likely works in release builds since they don't share anything global

mkvlr10:03:30

@thheller we got everything working after a shadow upgrade and another unrelated fix, thanks for having fixed things before we even asked for them!

👍 3
😂 3
sb12:03:17

Hello, I would like to create a clojure/script lib. I can solve the cljs part with shadow-cljs. My question is, of course I can push to Clojars libs, .. if I would like to push with .cljc files (cljs part with shadow-cljs), how do I need to setup the leiningen? or that isn’t possible (use from cljs part if somebody add my lib, or better add a separated cljs-lib)? (sorry for noob question in this topic, maybe somebody did similar, good one example, github repo) Thanks in advance! #justbeforeIstart

raspasov12:03:31

Also look at clj-new for a library template (just used it the other day, I also don’t publish libs too often) https://github.com/seancorfield/clj-new

sb12:03:03

my question is, if I add shadow-cljs to cljs part.. for the lib, is that will work problem less if .. somebody will add.. who didn’t use shadow-cljs just cljs? Just I didn’t see good simple example

sb12:03:53

eg https://github.com/day8/re-frame-debux, but not so good example.. I would like to create an api lib, which will work from clj and cljs (but in cljs rs256 signing works just with npm libs)

sb12:03:16

google crypt.. don’t have rs256 signing

sb12:03:29

maybe a bad question, I just try out

thheller13:03:38

shadow-cljs is not relevant when publishing libraries

thheller13:03:52

all you need is something that puts the .cljs files into a .jar

thheller13:03:58

they don't need to be compiled or anything

👍 3
thheller13:03:18

I use lein and just have the files as usual on the :source-paths

👍 3
sb13:03:12

Ok, thanks the info!

kommen21:03:49

after bumping ClojureScript to https://github.com/clojure/clojurescript/commit/69b66374d857a176c5a9cd8cc0cbb7506876640d we’re running into compile errors seemingly related to shadow:

IllegalArgumentException: No matching method setOriginalPath found taking 1 args for class com.google.javascript.jscomp.SourceFile$Preloaded
	clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:127)
	clojure.lang.Reflector.invokeInstanceMethod (Reflector.java:102)
	shadow.build.closure/convert-sources-simple*/iter--86592--86596/fn--86597/fn--86598 (closure.clj:1855)
	shadow.build.closure/convert-sources-simple*/iter--86592--86596/fn--86597 (closure.clj:1830)
	clojure.lang.LazySeq.sval (LazySeq.java:42)
	clojure.lang.LazySeq.seq (LazySeq.java:51)
	clojure.lang.RT.seq (RT.java:535)
	clojure.core/seq--5402 (core.clj:137)
	clojure.core.protocols/seq-reduce (protocols.clj:24)
	clojure.core.protocols/fn--8146 (protocols.clj:75)
	clojure.core.protocols/fn--8146 (protocols.clj:75)
	clojure.core.protocols/fn--8088/G--8083--8101 (protocols.clj:13)
	clojure.core/reduce (core.clj:6828)
	clojure.core/into (core.clj:6895)
	clojure.core/into (core.clj:6887)
	shadow.build.closure/convert-sources-simple* (closure.clj:1859)
	shadow.build.closure/convert-sources-simple* (closure.clj:1826)
	shadow.build.closure/convert-sources-simple (closure.clj:2117)
	shadow.build.closure/convert-sources-simple (closure.clj:2069)
	shadow.build.compiler/maybe-closure-convert (compiler.clj:1169)
	shadow.build.compiler/maybe-closure-convert (compiler.clj:1162)
	shadow.build.compiler/compile-all (compiler.clj:1414)

thheller21:03:13

its the closure-compiler changing stuff again

thheller21:03:30

can't fix that until there is an official CLJS release that works with newer closure-compiler versions

thheller21:03:04

just downgrade closure-compiler to v20210202

thheller21:03:12

actually I might be able to fix it. the alternative way of working with SourceFile is rather old so it might be ok. will see tommorrow

👍 6