Clojurians Log v2

Hello, I just tried adding an NPM package called https://gildas-lormeau.github.io/zip.js/ to my project, and compilation failed with this error about a missing Babel plugin:

SyntaxError: […]/node_modules/@zip.js/zip.js/lib/core/codecs/codec-pool-worker.js: Support for the experimental syntax 'importMeta' isn't currently enabled (82:72):

  80 | 	let messageTask;
  81 | 	if (!workerData.interface) {
> 82 | 		workerData.worker = new Worker(new URL(workerData.scripts[0], import.meta.url));
     | 		                                                                     ^
  83 | 		workerData.worker.addEventListener(MESSAGE_EVENT_TYPE, onMessage, false);
  84 | 		workerData.interface = {
  85 | 			append(data) {

Add @babel/plugin-syntax-import-meta (<https://git.io/vbKK6>) to the 'plugins' section of your Babel config to enable parsing.

Are there any consequences from the new npm require syntax for Shadow-cljs? Should we prefer the official statements now?

What are the official statements?

Source paths are ["env/test" "test/src"] - some environment configuration variables, and then all the test files. File hierarchy is e.g. test/src/myapp/test/db.cljs You’re right, the runner file remained from old solution. After removing it, same problem remains but for other files (e.g :expected-ns src.myapp.test.api.transform, :actual-ns myapp.test.api.transform)

the $ syntax has been in shadow-cljs for a long time too. it is a useful addition so use it when it make sense for you.

this is not currently supported but the library seems to contain a prepackaed version without the worker via (:require ["@zip.js/zip.js/dist/zip-no-worker.min.js" :as zip]) maybe that works for you

it looks like you have "test" on the classpath, which is the default when using lein via :test-paths ["test"]. You need to override that so the classpath doesn't contain duplicated entries.

but which shadow-cljs version is this with? either you are using a very old shadow-cljs version or something else is going on?

Using 2.11.18 right now. Looks like we didn’t have a :test-paths set in project.clj at all, so I tried setting it to ["test/src"] which seems to have solved the namespace issue! Now I get another error instead but it seems related to our own code.

@karol.wojcik https://clojurescript.org/news/news#_library_property_namespaces

I'm trying to set up a new project using shadow-cljs version "2.12.1". • compile works fine • watch throws piggieback-related exceptions • Both work completely fine if I revert to version "2.11.23" (happens to be the version I use on another project).

I can provide the specific exceptions if it would help.

@pmooser most likely you are using project.clj or deps.edn and have not bumped the CLJS version after bumping shadow-cljs

2.12.0 requires CLJS 1.10.844, which is why it did the 2.11 -> 2.12 bump

Sorry about that. I thought I used that version, but you must be correct.

Thank you.

Yes, that fixes it.

Ahh. That's that new one! 😄 Thanks @thheller 🙂

Hey. I'm still on my lein-figwheel -> shadow-cljs adventure 😉 Right now I'm trying to replace the cljsjs/clipboard code with the npm package. I've added the same version (1.6.1) with yarn, and required ["clipboard" :as clipboard]instead of cljsjs.clipboard. But how do I update this line?

(new js/Clipboard (rdom/dom-node button))

OK cool, that might work – I’ll give it a shot. Thanks!

@igel your are getting rid of the js/GlobalThingy references and just use it like any regular CLJS namespace

or in this case it is special since you are using it as a regular var

so just (new clipboard (rdom/dom-node button)). just using the :as clipboard directly

Thanks, the last suggestion was what I needed. 👍

in my experience, there is definitely no need to manage dependencies in deps or project.clj, just want to echo thhellers comment (I find that managing npm deps in shadow-cljs.edn is FAR less maintenance work than dealing with deps.edn or project.clj finagling I end up doing when working with npm deps in those)

Any idea what the error IllegalStateException: Externs must contain builtin for env BROWSER: whatwg_console.js is caused by? I'm trying to migrate everything to the newest cljs and shadow-cljs.

some classpath issue probably. maybe you excluded a dependency too much?

they should be part of the closure-compiler

Hmmm. I'll keep digging, thanks.

or maybe a good old guava conflict 😛

Yeah, I'm not sure. It doesn't happen with my old compiled artifact, but I happen to be trying pull in a local project (which I am also updating) via :local/root. So it's interesting that if I just use the old thing it's fine.

I've updated that project's deps (of course) ... but the code is all identical.

could be an issue in in shadow-cljs, cljs, closure-compiler. hard to say without more info.

Yeah. I'm going to stop for the day soon. I'll see if I can gather some more useful information in the morning.

oh, this should be in the closure-compiler-externs artifact I think. maybe you just excluded that by accident

or maybe you have a externs.zip on the classpath? 😛

shadow-cljs clj-repl (<http://clojure.java.io/resource|clojure.java.io/resource> "externs.zip") should give a clue

That yields:

"jar:file:/Users/taronish/.m2/repository/com/google/javascript/closure-compiler-externs/v20180805/closure-compiler-externs-v20180805.jar!/externs.zip"

I imagine those are old ...

that looks too old yes, I get

#object[java.net.URL 0x1a418fc7 "jar:file:/C:/Users/thheller/.m2/repository/com/google/javascript/closure-compiler-unshaded/v20210302/closure-compiler-unshaded-v20210302.jar!/externs.zip"]

I'm wondering why pulling in the local project that way makes it use ancient externs, assuming that is what is happening.

hmm so I guess that might be the reason. they seem to have combined it into the closure-compiler-unshaded and the separate closure-compiler-externs don't exist anymore?

I'm not personally sure where this comes from ... is there any way to "tell it" to use a newer one?

clj -Stree should tell you what is adding it

Hmm I wonder if I can just exclude that from wherever it is coming from?

you can, just :exclusions

That did it. Thank you very much.

good to know that might be an issue. did the lib have a direct dependency on the externs?

No - not that I can see anyway.

It is coming in because that project is pulling in: org.clojure/clojurescript 1.10.597

thats like ancient history, 2.12 should definitely be used with 1.10.844

Yes, it makes sense. I will talk to the library author and get him to update.

I'm wondering if this has been responsible for some other weirdness I've seen related to this library.

Thanks for helping me debug it - I would never have traced it back to externs like that.

what is the preferred way to do repl driven dev with shadow-cljs alongside tools.deps? I’ve got the backend using tools.deps and I would like to implement the front end with re-frame, but if I connect with vim/fireplace to the nrepl that shadow starts I can’t eval the backend related code because it cant find the libraries in the class path. Should I use tools.deps for both shadow-frontend/backend tasks?

thanks!

can fireplace open a second connection to your backend?

I’m not quite sure about that tbh

me neither but that would be the optimal solution

otherwise you could run shadow-cljs as part of your backend process, using the embedded mode https://shadow-cljs.github.io/docs/UsersGuide.html#embedded

is cider capable of doing that?

cider can do multiple connections I think yeah

👍

Is it expected that throwing an exception in Node.js REPL causes the runtime to exit? E.g.:

% shadow-cljs node-repl
shadow-cljs - config: /Users/dottedmag/w/hz/shadow-cljs.edn
shadow-cljs - server version: 2.12.1 running at <http://localhost:9630>
shadow-cljs - nREPL server started on port 52529
cljs.user=&gt; shadow-cljs - #4 ready!


(throw "x")


^C
The previously used runtime disappeared. Will attempt to pick a new one when available but your state might be gone.
cljs.user=&gt; Failed to read: clojure.lang.ExceptionInfo: Input/output error {:type :reader-exception, :line 2, :column 1, :file "dummy.cljs"}

Also the message about disappeared runtime does not appear until ^C