lumo

:lumo: Standalone ClojureScript environment. Currently at version 1.9.0
2017-11-12T17:46:45.000021Z

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.

richiardiandrea 2017-11-12T19:18:40.000037Z

Oh nice

richiardiandrea 2017-11-12T19:19:02.000066Z

I was looking for a way to make standalone apps

richiardiandrea 2017-11-12T19:19:28.000007Z

Do you have some sample setup by any chance?

2017-11-12T20:21:06.000138Z

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.

2017-11-12T20:23:47.000106Z

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

2017-11-12T20:44:14.000065Z

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.

anmonteiro 2017-11-12T20:48:40.000064Z

it’s not going to work for obvious reasons

anmonteiro 2017-11-12T20:48:56.000065Z

Lumo is a compiled Node.js

πŸ‘ 1
anmonteiro 2017-11-12T20:49:20.000047Z

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

anmonteiro 2017-11-12T20:49:44.000011Z

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

dominicm 2017-11-12T20:50:27.000019Z

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

anmonteiro 2017-11-12T20:51:34.000111Z

not portable to pkg last time I checked

anmonteiro 2017-11-12T20:51:55.000037Z

in theory they could be used separately

anmonteiro 2017-11-12T20:52:13.000041Z

however Lumo is in reality 2 things

anmonteiro 2017-11-12T20:52:44.000028Z

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

dominicm 2017-11-12T20:54:12.000043Z

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?

anmonteiro 2017-11-12T20:55:07.000053Z

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

anmonteiro 2017-11-12T20:55:25.000077Z

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

dominicm 2017-11-12T20:55:31.000055Z

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

dominicm 2017-11-12T20:55:42.000098Z

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

anmonteiro 2017-11-12T20:55:49.000061Z

right

anmonteiro 2017-11-12T20:56:01.000003Z

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

2017-11-12T20:56:35.000032Z

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.

dominicm 2017-11-12T20:56:58.000081Z

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

πŸ‘ 1
anmonteiro 2017-11-12T20:57:13.000072Z

put something together I can look at

anmonteiro 2017-11-12T20:57:24.000121Z

happy to have a Boot task or something

πŸ‘ 2