takeing it 1 step further, how can I override/js-resolve the node-repl, so that "mylib" within a .jar becomes "/mylib", this is for a project that I don't plan to build, just use the node-repl for live evaluation. To be percise, this :require https://github.com/hlolli/csound-wasm/blob/master/src/csound_wasm/node.cljs#L3 I'm hopeing to stay leagal from within a .jar file (so in another project I'm requireing this project).

therefore in this case I'm hopeing "libcsound" resolves to "/csound_wasm/libcsound"

is this not available from npm?

yes! 🙂 I'm hopeing to make this a clojurescript library, node library and a standalone browser js library.

I mean why not juset require "/csound_wasm/libcsound"?

it would probably work from the .jar, but within the project itself when compileing :node-library, it will complain.. I can try again

if you package that file in a .jar it should work for any build using that jar

it just has to be on the classpath

that's true, I bet it would, I'm going to see now if that will ruin the shadow-cljs release node compilation.

https://github.com/hlolli/csound-wasm/blob/master/shadow-cljs.edn#L6-L8

no don't

no :js-options at all

always just require "/csound_wasm/libcsound" not libcsound

yup that works! now confirming the .jar

but I do get some errors from "/csound_wasm/libcsound" that I didn't get from "libcsound" + :js-resolve. Namely

Closure compilation failed with 7 errors
--- csound_wasm/libcsound.js:81
Invalid module path "goog:shadow.js.shim.module$fs" for resolution mode "BROWSER"
--- csound_wasm/libcsound.js:82
Invalid module path "goog:shadow.js.shim.module$path" for resolution mode "BROWSER"
--- csound_wasm/libcsound.js:4253
Invalid module path "goog:shadow.js.shim.module$crypto" for resolution mode "BROWSER"
--- csound_wasm/libcsound.js:5166
Invalid module path "goog:shadow.js.shim.module$ws" for resolution mode "BROWSER"
--- csound_wasm/libcsound.js:5416
Invalid module path "goog:shadow.js.shim.module$ws" for resolution mode "BROWSER"
--- remaining errors ommitted ...

so ok, I guess it didn't compile then, I was running an older output

so what is happening there is that you have conditional requires

this file is kinda shit, automatically generated js->c/c++ patch from emscripten compiler

those are generally a bad idea and not supported

I wonder why it still differs, the :js-resolve and classpath require. The setup with :js-resolve, minified it all and didn't throw errors.

it is treated differently

hang on I'll check something

make: Entering directory '/mnt/c/Users/thheller/code/shadow-cljs/tmp/csound-wasm/node_modules/speaker/build'
  CC(target) Release/obj.target/output/deps/mpg123/src/output/alsa.o
../deps/mpg123/src/output/alsa.c:19:28: fatal error: alsa/asoundlib.h: No such file or directory
 #include <alsa/asoundlib.h>

guess its not available on windows

ahh, f** "speaker"

does osx work?

yes it should

I can test 1 sec...

success

they say for windows Windows: win32 Audio output for Windows (winmm). whatever winmm is, need to look into that. Webaudio in node.js is a strange world.

it might be because of WSL

where does the libcsound.js come from?

here https://github.com/csound/csound/blob/develop/Emscripten/build-wasm.sh

but I added this module.exports = Module at the end of the file. the minifier would otherwise not find the object.

ok so the compromise I made

was that the classpath should only contain ES6

but yours is commonjs with dynamic requires

so it should be treated like node_modules sources but isn't at the moment

let me see if I can reasonably change the behaviour

ok, otherwise I could see if it's reasonable to patch this file to become ES6 compatable, but that sounds daunting

ideally it wouldn't include the loading code at all

and would you just let pass in the wasm code

this seems to be work in progress https://github.com/kripken/emscripten/issues/5828

would be good if there was a way to generate libcsound_browser.js libcsound_node.js

so the file itself doesn't include any conditional loading code

hmm, then there's the rust to wasm compiler, seperate of emscripten one, looking at wasm discussion in the wild, seems to be an overtake from the rust community.

yup aggree, I bet this will be improved soon

no they use emscripten seemingly... nvm...

meh this commonjs handling code of the closure compiler hurts my head

I'll probably add a new source type that isn't processed by closure at all

and just copied as is to the output dir

that should resolve the problem for node

I would still be tempted to compile it with js-resolve and change the require form and then bundle the jar. But the feature of ignoring certain js deps to be processed by closure is going to save headaches.

No quatsch, wont work :)

Yes I really need to ignore option for the jar.

how come you don't just publish libcsound.js to npm independently?

That was my initial plan. Was curious of the new features in shadow-cljs. But from this position, sounds way easier

well closure is getting in the way here

Invalid module path "goog:shadow.js.shim.module$fs" for resolution mode "BROWSER" this I can fix easily

Or the third option, i dont make a jar at all and require the npm

jar for cljs is fine. jar for es6 is experimental but should be fine. jar for commonjs is broken.

Yes, then I dont stress about this, bundle the libcsound when/if emscripten compile better js binding files

the problem is that I can't stop closure from rewriting require

but it shouldn rewrite require("fs")

Well, deep in this emscripten js jungle is their own FS bindings. So I could see why this confuses the compiler

Node 4.x filesystem bindings

nono the problem is that closure rewrites require calls

and replaces them with direct variable references

but it shouldn't rewrite those requires

it feels like integrating so heavily with google closure was not a good move for CLJS 😞 a lot of problems with CLJS today are caused by it’s dependence on it

@lilactown CLJS does not depend on it at all. I could do everything without the CLJS compiler. Closure is just far beyond every other JS tool out there when it comes to optimizing JS and I personally don't want to give that up.

we are just using the closure compiler for things its not yet super optimized to do

so technically CLJS doesn't have any issues with closure. non-closure-js has.

could be using babel for that part but I wanted to enable DCE for .js on the classpath

that might be a dead-end so I should probably opt out of that for now

already opted out for node_modules