Fork me on GitHub
#lumo
<
2017-11-12
>
hlolli17:11:45

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.

richiardiandrea19:11:02

I was looking for a way to make standalone apps

richiardiandrea19:11:28

Do you have some sample setup by any chance?

hlolli20:11:06

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.

hlolli20:11:47

ah fuck, haha I seemed to have been overrateing the success of this whole thing, it actually didn't package lumo into the binary

hlolli20:11:14

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.

anmonteiro20:11:40

it’s not going to work for obvious reasons

anmonteiro20:11:56

Lumo is a compiled Node.js

anmonteiro20:11:20

what pkg and the sorts do is bundle your JS inside a compiled Node.js

anmonteiro20:11:44

you would need to include your CLJS or something inside the Lumo binary, not an ordinary Node.js

dominicm20:11:27

@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?

anmonteiro20:11:34

not portable to pkg last time I checked

anmonteiro20:11:55

in theory they could be used separately

anmonteiro20:11:13

however Lumo is in reality 2 things

anmonteiro20:11:44

the serialized heap bytecode (result of CLJS compilation) and the entry point that boots Lumo (the JS code in the repo)

dominicm20:11:12

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?

anmonteiro20:11:07

pkg, nexe or whatever tool you use, they always require a JS file to be the entry point

anmonteiro20:11:25

even if that file is just calling into an exported function from your CLJS bytecode

dominicm20:11:31

When I say "the build pipeline" I meant as part of lumo's.

dominicm20:11:42

"forking" lumo to add custom code, in essence.

anmonteiro20:11:01

that would be the way to build a custom binary with your code

hlolli20:11:35

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.

dominicm20:11:58

@anmonteiro how welcome would any tweaks to make it easier in core lumo to make that kind of build?

anmonteiro20:11:13

put something together I can look at

anmonteiro20:11:24

happy to have a Boot task or something