Fork me on GitHub
#shadow-cljs
<
2021-04-07
>
Stuart Campbell05:04:48

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 () to the 'plugins' section of your Babel config to enable parsing.
I found https://github.com/thheller/shadow-cljs/issues/190 but I wasn’t sure how to proceed. One comment in there suggested that .babelrc could somehow be used, but I’m not sure if that’s applicable here.

thheller07:04:42

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

Stuart Campbell15:04:53

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

David Pham05:04:23

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

Karol Wójcik07:04:58

What are the official statements?

thheller07:04:07

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.

Karol Wójcik13:04:39

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

pmooser12:04:44

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).

pmooser12:04:38

I can provide the specific exceptions if it would help.

thheller12:04:05

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

thheller12:04:42

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

pmooser12:04:39

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

pmooser12:04:40

Thank you.

pmooser12:04:34

Yes, that fixes it.

iGEL15:04:56

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))

thheller16:04:29

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

thheller16:04:42

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

thheller16:04:53

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

iGEL16:04:24

Thanks, the last suggestion was what I needed. 👍

pmooser18:04:12

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.

thheller18:04:02

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

thheller18:04:49

they should be part of the closure-compiler

pmooser18:04:53

Hmmm. I'll keep digging, thanks.

thheller18:04:36

or maybe a good old guava conflict 😛

pmooser18:04:17

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.

pmooser18:04:29

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

thheller18:04:49

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

pmooser18:04:18

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

thheller18:04:39

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

thheller18:04:29

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

thheller18:04:03

shadow-cljs clj-repl ( "externs.zip") should give a clue

pmooser18:04:09

That yields:

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

pmooser18:04:18

I imagine those are old ...

thheller18:04:35

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"]

pmooser18:04:55

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

thheller18:04:32

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?

pmooser18:04:00

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

thheller19:04:10

clj -Stree should tell you what is adding it

pmooser19:04:20

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

thheller19:04:37

you can, just :exclusions

pmooser19:04:00

That did it. Thank you very much.

thheller19:04:39

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

pmooser19:04:51

No - not that I can see anyway.

pmooser19:04:13

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

thheller19:04:28

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

pmooser19:04:55

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

pmooser19:04:09

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

pmooser19:04:29

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

yiorgos19:04:24

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?

thheller19:04:35

can fireplace open a second connection to your backend?

yiorgos19:04:49

I’m not quite sure about that tbh

thheller19:04:07

me neither but that would be the optimal solution

thheller19:04:18

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

👍 3
yiorgos19:04:22

is cider capable of doing that?

thheller19:04:59

cider can do multiple connections I think yeah

dottedmag20:04:44

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 
shadow-cljs - nREPL server started on port 52529
cljs.user=> 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=> Failed to read: clojure.lang.ExceptionInfo: Input/output error {:type :reader-exception, :line 2, :column 1, :file "dummy.cljs"}

dottedmag20:04:55

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