I'm trying to read this to understand a little better: https://github.com/thheller/wasm-pack-cljs

What I'm trying to do is migrate to the new automerge 2.0 project: https://automerge.org/blog/automerge-2/

for some reason they use

const { TextDecoder, TextEncoder } = require(`util`);

so backtick instead of quote

this is not currently supported I guess

you can open a ticket for what, that is fixable

however I'm less optimistic about the wasm working 😉

const path = require('path').join(__dirname, 'automerge_wasm_bg.wasm');

will definitely 100% not work in the browser

I give that package a 0% chance of working with shadow-cljs 😉

maybe if you go through webpack via https://code.thheller.com/blog/shadow-cljs/2020/05/08/how-about-webpack-now.html#option-2-js-provider-external

@thheller Thank you so much for your detailed response! I will take a look at that webpack thing ... is it possible to use it just for one library?

nope, all or nothing

Ok, that is indeed how it appeared from the web page.

@thheller So if we use the :external js provider like that, is it still possible somehow to use shadow-cljs for interactive development (like with hot reloading and stuff)? Because if I understand the order of operations correctly, first we invoke shadow-cljs, which generates a js file, which then we feed into webpack, and then we have our index.html load both files ...

Is the idea that if I don't change the js requirements often, we don't actually have to do the webpack step very often, and we can just sort of use shadow-cljs like normal?

yes, the only part that changes is that you can't dynamically change JS dependencies

otherwise hot-reload works as before

Ok. I'm learning this stuff very slowly and I will give it a try. Is there any hope for more seamless support for WASM eventually, or is that really just dependent on the dust settling in the WASM ecosystem?

eventually when there is a standard for this yes

right now every wasm lib seems to do its own weird non-standard stuff

most are specifically tailored for webpack

Ok, that seems very reasonable.

Thank you!

@thheller I sort of got it working (the build with webpack), but even after getting it to load the wasm and stuff, I seemingly can't resolve anything in the automerge package itself. Any further suggestions for debugging?

I suppose the concrete issues I'm seeing are not being able to use anything from automerge (like calling Automerge/init doesn't work - it can't find it), but also I think something about the build related to my inclusion of io.github.nextjournal/markdown didn't work, because I get this error upon loading:

this is not an error you would get from a :js-provider :external build

so I suspect you might be loading some outdated files. might be cache, might just be outdated files when you changed filenames or something

Ok, thanks - I will try clearing out everything and seeing if that helps.

No, I get exactly the same issue and error. I'm wondering if maybe some js or something is bundled in the nextjournal markdown project which is then somehow not visible to webpack.

All I am doing in terms of procedure is a shadow-cljs compile of my build, and then npx webpack (with a suitable config just telling it what to read from and where to write to) ...

without seeing configs/code I cannot say much

Yeah. I am going to try to see if I can make it work with bare cljs, just to have some info from that perspective, with a new barebones project that just pulls in Automerge 2. If I manage to make THAT work, maybe I'll bug you about shadow-cljs.

I'm happy to take a look at a repro that is failing, just need something to look at :P

Thank you very much for that - my company won't let me share what I am doing directly, but maybe I can make a simple repro case.

:target :file is really not recommended. neither is the :resolve config

better to use :js-package-dirs ["node-modules" "your-modules"] in the build config

then have your webpack output go to your-modules/all-gql-queries/index.js

but be careful with running secondary bundlers, it may lead to duplicated packages

I don't know why you have the global stuff

just use js/UserGqlQuery?

> but be careful with running secondary bundlers, it may lead to duplicated packages this is just for import .gql files directly into JS bundle Tomorrow I will try to access the globals directly. Maybe even add the external script src= and leave the cljs build way cleaner.

I don't know what .gql files are, but webpack in the process of bundling them might include npm dependencies

that shadow-cljs may not see and maybe import again

GraphQL query files

I guessed as much

I had a project where I included something from src/deps.cljs in peerDependencies, and found that shadow would try to install it every time. The problem was that the npm install call that shadow issued would destroy any npm link calls I had run, to get npm to look at local versions of one of the dependencies I was working on

uhm aren't peerdependencies only relevant in libraries?

I don't even know what npm link is, so no idea about that

same with devDependencies, right?

I'm not really understanding your question I guess

@thheller you use npm link when you have an npm dependency like mathbox, and you want to develop against local copy of it

I was working a library that declared mathbox as a peerDependency

doesn't peer dependency just mean "don't install it" when you run npm install?

it means “required but you bring your own version”

it actually DOES install by default

wait, sorry, let me be clear

if I declare a peerDependency in my own project, it is definitely installed. if someone then depends on me, npm install actually WILL install my declared peerDependencies; but usually it’s like a JVM “provided” dependency. It means “consumers have to have SOME version of this but I want to force you to declare it on your own”

“npm link” replaces the node_modules entry of a library with a symlink to a local path. the problem is that shadow-cljs is calling npm install inappopriately, since its is-installed? filter is not catching things I have in peerDependencies; and that npm install call blows away my npm link symlinks

so why do any of this at all?

?

say more

I'm still seriously considering removing npm-deps install thing entirely

it has been nothing but trouble 😛

you can set :npm-deps {:install false} in shadow-cljs.edn

then how do I ship libraries like https://mafs.mentat.org/, https://jsxgraph.mentat.org/ etc…

then it won't do anything 😛

I want it to install dependencies!

I just want it to realize that I’ve already installed stuff in peerDependencies

it’s great, I think it would be a sad experience to have to tell users to manually install the npm deps my libraries are building on, especially multiple levels deep; users shouldn’t be manually resolving dependency trees

but shipping libraries is entirely different from developing libraries

I develop, then I ship…

so you during development can skip the automated install entirely, especially if you are doing npm link and whatever

the end user can still install everything normally, without any of your custom things going on?

ah, I see what you’re saying

I mean I'm fine with adding peerDependencies in the lookup stuff

but doesn't seem like that would totally prevent this from accidentally nuking your custom setups

yeah, you’re right that it would still nuke them the first time, until the deps.cljs entries had made it into package.json

so this is good to know for sure

but you are a developer of a library, should not be dependent of transfering your OWN npm dependencies out of deps.cljs if you ask me

you should manage and maintain your own package.json

and more importantly your own lock files

including keeping them in git

what the end user gets is entirely different story if you ask me

I even go so far as having an entirely separate package.json file for published packages

> but you are a developer of a library, should not be dependent of transfering your OWN npm dependencies out of deps.cljs if you ask me I agree but this happens automatically if you include a src/deps.cljs in your classpath

then don't include it 😛

https://github.com/mentat-collective/JSXGraph.cljs/blob/main/shadow-cljs.edn#L1

it comes in via my :deps dependencies

I’m not sure what problem I solve by excluding it? I basically don’t want to care at all about npm after declaring the dep, so it actually feels like the right thing to do to get my deps in via deps.cljs

what if I forget to add something new to it, or update a version

I mean I totally trust you that deps.cljs is causing trouble, you’re the expert here… maybe I’m too used to the status quo to imagine other solutions

does this work with regular cljs?

https://github.com/mentat-collective/Mafs.cljs/blob/main/src/mafs.cljs#L1-L3

ie. having a cljs namespace including a npm package of the same name?

it doesn't right?

shadow-cljs has a special case where a string always only refers to JS requires

in regular CLJS (:require ["clojure.string" :as x]) is valid, which I consider a bug

but I'd assume that the ["mafs" :as m] is treated as a self-require and would error out?

also single segment namespaces in cljs are kind of problematic, so not recommended

sorry looking now

@thheller I had asked here a while ago and it sounded like it was supported; `“mafs” here is an npm dependency

@thheller I should probably rename the cljs namespace mafs.core

> but I’d assume that the ["mafs" :as m] is treated as a self-require and would error out? I have only tried it with shadow, where it works fine… I should get a proper vanilla build going

I mean if you are care just mafs is fine

but I don't think the regular CLJS build process will like that

yeah, you’re probably right. I should change it and folks can always alias