fun fact, if you use node to spawn lumo as child process, then you can bundle it with https://github.com/zeit/pkg, remindes me of lein-bin except that with lein-bin you have to deal with .jar resources bundling shit.
Oh nice
I was looking for a way to make standalone apps
Do you have some sample setup by any chance?
I tried it for example on my test example for a ticket I wrote https://github.com/hlolli/lumo-repl-noqueue-benchmark just did
npm install -g pkg
pkg test.js
there I had three binaries for osx, linux and windows, easy.ah fuck, haha I seemed to have been overrateing the success of this whole thing, it actually didn't package lumo into the binary
By adding "pkg": {
"assets": "./node_modules/lumo-cljs/bin/lumo"
}
into the package.json and running pkg with -c package.json
flag, turns the binary into 100mb. But it's still not working, I'll try to figure it out, and maybe for once write a blog post if I'm successful.
itβs not going to work for obvious reasons
Lumo is a compiled Node.js
what pkg and the sorts do is bundle your JS inside a compiled Node.js
you would need to include your CLJS or something inside the Lumo binary, not an ordinary Node.js
@anmonteiro your tricks to get google closure to cache nicely, how "portable" are those? Could they be used with pkg independently of lumo quite easily, for example?
not portable to pkg
last time I checked
in theory they could be used separately
however Lumo is in reality 2 things
the serialized heap bytecode (result of CLJS compilation) and the entry point that boots Lumo (the JS code in the repo)
I wonder how hard it would be to hook that up with some additional cljs code in the build pipeline. That would presumably be the way to tackle this?
pkg
, nexe
or whatever tool you use, they always require a JS file to be the entry point
even if that file is just calling into an exported function from your CLJS bytecode
When I say "the build pipeline" I meant as part of lumo's.
"forking" lumo to add custom code, in essence.
right
that would be the way to build a custom binary with your code
yes, my idea was seperating the two, js entry point to lumo. Otherwise it would have to be done I guess when compileing the lumo binary, which could be a boot task or something that loads user cljs code.
@anmonteiro how welcome would any tweaks to make it easier in core lumo to make that kind of build?
put something together I can look at
happy to have a Boot task or something