This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (2)
- # beginners (184)
- # boot (18)
- # cljs-dev (8)
- # cljsjs (7)
- # cljsrn (4)
- # clojars (2)
- # clojure (393)
- # clojure-boston (2)
- # clojure-dusseldorf (1)
- # clojure-gamedev (36)
- # clojure-greece (2)
- # clojure-italy (1)
- # clojure-russia (11)
- # clojure-spec (27)
- # clojure-uk (7)
- # clojurescript (69)
- # core-async (16)
- # cursive (25)
- # datascript (1)
- # datomic (34)
- # events (1)
- # funcool (1)
- # hoplon (1)
- # interop (1)
- # klipse (1)
- # leiningen (2)
- # lumo (75)
- # off-topic (19)
- # om-next (2)
- # onyx (66)
- # re-frame (18)
- # reagent (2)
- # ring-swagger (11)
- # spacemacs (1)
- # specter (1)
- # timbre (3)
- # untangled (48)
- # yada (7)
is there any support for loading .cljs namespaces from node_modules? sorry for my ignorant questions, just trying to gauge the possibilities... could npm packages be used to distribute libs for lumo as an alterantive to clojars?
@futuro thanks for the links BTW, that's exactly the kind of stuff I was looking for earlier!
so that doesn’t work right off the bat, but you can make it work with
lumo --classpath node_modules/your-module/the-modules-src-dir
I wonder if we could support CLJS
require by indexing
node_modules folders implicitly
ok, that's what I thought. Would be a really cool feature :slightly_smiling_face: Right now it seems using an npm package for JS stuff is significantly more straightforward than using a package from Clojars.
that’s interesting feedback. created https://github.com/anmonteiro/lumo/issues/130
or I could just push the 1.4 release to next week and finish that work this week :slightly_smiling_face:
is this referring to modifying the classpath, or to loading from node_modules? ("probably won’t be in the next version (1.4), but definitely in 1.5")
do I have it right that 1.4 will make it possible to require js files like namespaces?
the Node module support that shipped with 1.9.518 is about converting CommonJS modules to Goog modules
that said, Lumo also supports compiling CLJS projects (with optimizations), and we also want to implement that support in future versions. But that’s not going to be in 1.4
yeah, so I've been using
js/require in my scripts, but I thought with 1.9.518 I would be able to use CLJS (require ...) instead to do the same thing. I might be missing some bits here :slightly_smiling_face:
to give more context on the classpath thing, my objective is to roughly have the same API as
There is potential risk (I assume) that this will lead to collisions, as things will resolve… differently to that of Aether. Especially as dependencies nest in node, where they are flat in jvm.
definitely true. I'm thinking this would be mostly for things that exclusively target lumo and hence are only on npm. But perhaps it makes more sense to improve the experience with clojars, perhaps moving some stuff from calvin into lumo, or making calvin more a first class "blessed" package manager. (just thinking out loud here)
I first had a hard time getting calvin running, but think I had an outdated version in node_modules somewhere that caused trouble. Now that it works it's pretty sweet. I just submitted a patch so that it passes extra arguments on to lumo, this way you can do
calvin repl -m my-app.core and have calvin take care of the classpath for you.
I feel like eventually someone will solve the classpath problem in a very happy way, & we'll end up with a new lein/boot/make/etc. that can handle it all for you.
Currently mach shells out to boot to calculate the classpath (and does some caching so it doesn't kill lumo unless you change the dep). I imagine shelling out to mvn would be faster though, but many don't have maven itself installed.
Another option is for this build tool to wrap up aether into a tiny java cli of some kind that you "lug" around, and it calls
java -jar aether-wrapper.jar cp -d "juxt/bidi:0.2.0" -d "juxt/yada:1.5.0" or something
This will be more effective with java 9 once you can strip down that jar really small.
I think this probably will go away given the pieces of the jigsaw (eh, eh :wink:) fall into place
That could also work. I hear maven is really complex in it's rules about arithmetic. So I fear a js based one would ultimately not work.
Well, it would work, it wouldn't be correct. I live in constant fear of things not being correct. I may be overly paranoid though ¯\(ツ)/¯
define "correct" :slightly_smiling_face: I find Java's dependency resolution entirely unintuitive and arbitrary at times. I've looked hard to find a description of the algorithm, but such documentation does not seem to exist.
so yes, if anyone ever decides to reimplement this in JS or CLJS it will probably behave slightly different. I can live with that.
so this just happened:
[email protected]:/# time ./lumo -e :foo :foo real 0m0.113s user 0m0.100s sys 0m0.010s
There was an idea here to use GWT java to js converted in aether, nobody has done it yet, but it is possible :grinning: