usually you want to follow the npm package guide on how to package them with webpack

happy to help you with the shadow-cljs side of things, webpack I'm out 😛

also as I recently learned some packages just work with shadow-cljs, no webpack required

so it all varies greatly 😛

that was https://github.com/thheller/cljs-webpack-build-woes

besides setting :js-provider :external and knowing its not easy to reload npm deps when you do this, there isnt much needed for shadow to produce js files consumable by webpack

best to setup a repo showing what you want to do and how far you got

https://code.thheller.com/blog/shadow-cljs/2020/05/08/how-about-webpack-now.html#option-2-js-provider-external: serves as a decent reference though

https://shadow-cljs.github.io/docs/UsersGuide.html#js-provider-external

Totally understand that! This was more a question as to whether such an example or guide exists, not a demand to have all answers served on a platter 🙂 I need to look into https://automerge.org/, which has popped up previously I saw, and there are no easy answers with that one. However, I got basic webpack up and running (without Automerge), so that’s fine. What’s odd is that first compile works fine, and then when shadow recompiles, it can’t infer the types of some things it seems.

I’m guessing this might have something to do with the output of webpack, but why first compile works and recompile does not is kind of weird.

go is pretty bad when it comes to inference and type hinting, so thats pretty common. try to move all code that does any kind of interop out of go blocks

happy to take a look if you setup a repo where I can reproduce this

using webpack generally means that shadow-cljs is not processing the JS code, therefore has less information about potential externs

thus leading to potentially more warnings about inference

OK, that’s definitely good to know. Shadow has been forgiving with me up until webpack. It’s a wrapper around Auth0, so I might have to do some promise interop instead of returning channels then.

don't use core.async for promise interop, if that is the only use of core.async you have

https://clojureverse.org/t/promise-handling-in-cljs-using-js-await/8998 much less pain involved with this

No, not the only reason, it’s part of a larger async chunk of stuff happening. But I can move the border of core.async away from being that far into the Auth0 stuff, shouldn’t be a problem.

Btw, speaking of async stuff, I don’t know if you’ve played with virtual threads on the JVM yet, but I’m really impressed by it. They’ve more or less found a way around function coloring. I can’t think of a less intrusive async solution out there.

yeah its nice, but I don't expect it to be ever available for JS 😛

I’m a dreamer

Alright, starting to see why this is hopeless now. I’d forgotten that I have dealt with WASM loading before, when writing a plugin for an editor. The methodology is to make module loads async, and basically have your own code be the last in a long chain of async loads.

Found a very ugly, but functional, workaround at least.

You probaly know about it already but the promesa library can make this type of async waiting (e.g. for wasm module load) much saner. It is probably also possible to inline the wasm code to base64 (or ArrayBuffer definition) into your build so it doesn't have to wait for a network request.

Thanks @UUSQUGUF3! In this case, I don’t have control over the loading behaviour, since I’m not the one developing the library. And I do want to stay up-to-date with the lib if possible. Otherwise, indeed, I could control the loading of the WASM. I ended up compiling a different JS file for Automerge, put it in a different script tag, and then I await it being fully loaded before utilizing it. I delay loading the main app until AM is fully loaded, since I don’t want async code to infect every aspect of the app.

npx shadow-cljs info has some basic info

That worked perfectly. Thanks!

my imports are setup like so:

(:require
   ["libphonenumber-js" :refer [getExampleNumber parsePhoneNumber formatIncompletePhoneNumber]]
   ["libphonenumber-js/mobile/examples" :as exampleNumbers])

i think you are seeing an error from the runtime react as described here: https://sentry.io/answers/defining-proper-key-in-props/

ie, you have a collection of items and two of them have the same key so react is getting confused. it doesn’t have a good “name” for each item

ah yeah, I'm familiar with this from react processing lists/options, but first time seeing this thrown with imports. thank you!

i’m questioning if this is from imports or rerendering your application

i don’t think this is a source code problem

yeah, this has nothing to do with the :require forms. it is from react :key using AS twice in the same collection. could be that the required examples have that, but that doesn't mean the require is bad 😛