Clojurians Log v2
lumo
My 2c @yogthos. I so so like the npm approach actually and using it with profit :) I basically pull all my deps from it except for expound and humane-test-output. Cljs deps are way less frequently updated and maintained... Something shadow-cljs is doing is to use deps.edn directly for building the classpath, shelling out to clojure. Either that or tools.deps will need to be somehow ported to self host...it probably won't happen any time soon.
I am building the classpath with clojure -Spath now in a script but would love to see it automatically happen in lumo.
how would you handle the classpath resolution for cljs libs on npm?
things would end up in npm_modules, so it should be predictable
npm would take care of dependency resolution, and then populate the libraries in standard locations, so lumo should be able to look for them there automatically
I had a discussion with thheller about this, and he had good arguments against putting .cljs files into npm modules. Forgot what he had in mind, but if you have a npm module with cljs files, even tough you could add that location into the classpath, there are going to be many problems packageing something that depends on this, and for that module to depend on other dependencies, be it node or other cljs lib.
yeah I can't really think of what the issue would be either, the nice thing with using package.json is that it's already built into npm and you're going to need to use one anyways when distributing things
yes so the only question there was whether we needed a lumo section or not. It was choosen not too and directories has been repurposed. Actually not repurposed. This is still open for discussion of course: https://github.com/anmonteiro/lumo/issues/130
so sounds like the issue with npm_modules is that other libraries could potentially mess with that, but that seems like a low risk problem to me, and having something like lumo or cljs reserved for the classpath would address majority of cases
it might also make sense to default to using npm_modules as the default, and allow using lumo.edn optionally
totally agree with you
so if you wanted to have more control over where dependencies are placed, you could opt into that
in any case at the moment we are not planning to release for broader JS consumption
packages there are just wrappers of cljs
right, the packages would just contain cljs files for lumo to use
yep so for instance https://github.com/jkk/honeysql/blob/master/package.json#L19
yeah that seems quite reasonable
I wonder if it might make sense to start publishing cljs libs on npm as well as clojars
I am pushing for that as well, I am at the moment consuming macrovich from npm and I see big value in that because a lot a lot more people are working (ok to be fair also breaking) the tooling around it 😄
Actually I also published https://www.npmjs.com/package/@arichiardi/humane-test-output
But it is a fork
First class eval for self-hosted landed in ClojureScript master 🙂
https://github.com/clojure/clojurescript/commit/a095d308484fa2ccea11b6d7256fb310d5d57c33
@mfikes@mfikes@mfikes@mf
wtf, my slack client is weird
my question is, does that mean macros can be compiled and called directly, without $macros namespace?
No
It is just an implementation of clojure.core/eval but for self-hosted ClojureScript, or regular ClojureScript that somehow defines cljs.core/*eval*.
ok, I thought that the limitation of macros in clojurescript was due to the lack of "real" eval, therefore compilation stage before clojurescript start was needed to make them run, but as you pointed out in an old blog article on macros, is that they can indeed be called on runtime, if one uses $macros namespace to call them (otherwise the return just macroexpand).
@hlolli It is probably feasible to revise the ClojureScript compiler so that self-hosted would allow intermixed macros and functions in the same namespace, just like Clojure. This has always been the case with self-hosted ClojureScript.
Support for cljs.core/eval has now landed on Planck master; Lumo can likely easily do the same.
this is not a self-hosted issue, it's not possible to intermix macros and functions in one .cljs namespace? In a piggyback based node-repl started via jvm I get the same macroexpand in runtime from macros.
it's my habit of putting them in .cljc files or .clj files so I'm not sure if my memory is right 🙂