didnt we go over this before? shadow-cljs does not support bundling .wasm files. so it any sources do import ... from "./some.wasm" that will fail, as shadow-cljs expects to find a file with JS syntax, which a .wasm file is not

as such you get the above parser error

No, in fact, this is in line with the last thing we discussed - where we left this was, with the race condition introduced by webpack, this may be impossible, but in fact if I can load the wasm asynchronously and pass it to the library itself that needs it to be initialized, it might work, without needing any kind of special bundling from shadow-cljs or webpack or anything.

I can try to dig up that thread but I'm reasonably certain that's where we left it, so that's why I'm trying to go back and remove the webpack bundling.

thats what led you to webpack in the first place. shadow-cljs cannot process this. webpack can, but implies that the loading mechanism becomes async

No, that's not the conversation we had.

I'll look for the thread.

well the facts haven't changed so I doubt I said anything different

automerge moved from something where you can supply the wasm yourself

to something were it relies on the bundler supplying it

It appears quite clear.

yes, exactly. that would be an option, but it was a hypothetical for something that doesn't exist in automerge

Ok, what aren't you understanding?

It does exist in automerge in fact -

that's entirely what I'm talking about.

That's why I said "if I can load the wasm asynchronously and pass it to the library itself" ...

ok. there is a misunderstanding here I guess.

the error you just posted that started this thread

I assume you get when you (:require ["@automerge/automerge" :as whatever])

Yes, I'm just including:

["@automerge/automerge/next" :as am]

ok, and doing ONLY that yields the above error?

I'm trying to figure out how I would remove all references to automerge in the code, since this is an existing codebase that goes back years (but of course used a different version).

I don't see any of my debugging logs get emitted that would occur when I try to do something with the module ...

ok, let me put it another way. some of the transitive dependencies brought in by your automerge require ends up doing import ... from "./automerge_wasm_bg.wasm" which shadow-cljs is trying to process but cannot

and since its in those files you cannot configure or remove it, well unless you are willing to rewrite automerge

Ok, so if I understand correctly then, since this just happens as a byproduct of that require, there's actually no workaround, unless I have a local version of automerge that doesn't perform such an import automatically.

Thank you for your help.

I think that's enough for me to go back and talk to the automerge folks again.

the screenshot of the JS example you posted isn't maybe clear enough about what structure you'd need for CLJS, so let me give a second snippet to complement

import * as Automerge from "@automerge/automerge";
let wasm = await fetch_util("/some/location/automerge.wasm");
let doc = Automerge.init(wasm);

the goal being that wasm can be supplied by other methods than just import

this would enable YOU to just take that wasm file out of node_modules, put it on your server, load it via fetch or whatever in CLJS and start automerge that way

Yes, so like I mentioned, they do have such a facility in automerge, and it is in use by something else already (not a clojure project) ...

without shadow-cljs ever knowing or caring that you use wasm files

And I think the fact that the main project imports stuff from the automerge-wasm project results in this breaking for us from a cljs perspective.

Anyway, I do understand what you're saying. Basically the automerge project itself can't actually have project references to the wasm project, or they'll get loaded transitively.

yes, as this is a non-standard feature not all bundlers support. and no browsers at all.

so basically expecting you to use webpack, but for webpack to do all this has to make the entire loading process async

thus leading to your race conditions

the issue is that you could configure shadow-cljs to just ignore this wasm require

but the code using that require is expecting it to be available, so it will fail regardless

Ok, thank you thheller.

> Yes, so like I mentioned, they do have such a facility in automerge

as far as I understood it they *used* to have this, but removed it in favor of the package dealing with it internally

at least as far as I can tell from looking at the code

since there is a non-optional import * as wasm from "@automerge/automerge-wasm"; in line 55 here https://unpkg.com/browse/@automerge/[email protected]/dist/mjs/stable.js and the line after that immediately using it. no chance to do anything async inbetween.