You can have macros that expand differently depending on target expansion context. For portability, either depending on https://github.com/cgrand/macrovich or using its ideas seems compelling.
@hlolli You could perhaps instead have the JavaScript loaded as a foreign lib (by putting a :foreign-libs
spec in a deps.cljs
file which is on Lumo's classpath.)
@mfikes yes I was wondering how to use foreign-libs in lumo, didn't know about the possiblity of deps.cljs, nice. I also tried some macros but didnt work, I was tempted to (js/require ..) before every namespace decleration, I research alternatives to avoid that at all cost. Thanks for these hints!
Planck has copied Lumo's deps management code, and I've queued a change to Planck's documentation that explains this use of deps.cljs
https://github.com/mfikes/planck/blob/master/site/src/dependencies.md#foreign-libs
There could probably be a shared doc between Planck and Lumo, nice work Mike :)
Hah, yeah, a lot of the surface area of Planck and Lumo is identical.
There is abio
Right, abio is an attempt at making an abstraction layer for I/O
Actually, its name is not derived from ab stract I/O, but it fits ๐
Wondering if abio could simply host abstractions & documentation for self-hosted cljs generally I guess. Maybe out of scope.
Would be nice to have something like this somewhere:
== Command Line Arguments
Command line arguments are accessible under `cljs.core/*command-line-arguments*`.
WARNING: Lumo used to have `lumo.core/*command-line-arguments*` but removed it in 1.7
INFO: Planck still maintains `planck.core/*command-line-arguments*` but should be considered deprecated as of X.Y
fwiw, the namespace problem above had in the end little to do with namespaces, found out that loading wasm file was causing a delay and I ended in callback hell situation. Solved beautifully by core.async, love core.async.
Hi again @richiardiandrea I want to brain storm the boot-clj on Node.js GSC project we talked about earlier. First to make sure its the same idea I had before learning it was already a GSC proposal and secondly to make sure i understand the project goals and benefits. My main goal was to help people create quick command line scripts (api calls, file io, etc..) from the command line. Lumo does a lot of that already, but the missing piece seems to a good library to take command line arguments. I spent the last couple week using Rubys Rake and before that a python library called โclickโ. I felt both were less flexible then boot. Rake in particular seemed like to much of a DSL without much gain. So assuming the idea is good, which iโm not sure how to verify. Then the next challenge for me is breaking down this task into bitsizes pieces so i can make headway. Any advice on either part would be great!