This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-17
Channels
- # bangalore-clj (2)
- # beginners (202)
- # boot (18)
- # cljs-dev (8)
- # cljsjs (7)
- # cljsrn (4)
- # clojars (2)
- # clojure (401)
- # clojure-boston (2)
- # clojure-dusseldorf (1)
- # clojure-gamedev (36)
- # clojure-greece (2)
- # clojure-italy (1)
- # clojure-russia (16)
- # clojure-spec (27)
- # clojure-uk (7)
- # clojurescript (68)
- # core-async (16)
- # cursive (25)
- # datascript (1)
- # datomic (34)
- # funcool (1)
- # hoplon (1)
- # interop (1)
- # klipse (1)
- # leiningen (2)
- # lumo (75)
- # off-topic (17)
- # 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!
@plexus there are no ignorant questions if there’s no docs to enlighten you
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 🙂 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
@plexus technically there’s nothing stopping us from doing that
there’s work in progress to make it work
probably won’t be in the next version (1.4), but definitely in 1.5
or I could just push the 1.4 release to next week and finish that work this week 🙂
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")
classpath
FWIW there’s work here https://github.com/anmonteiro/lumo/tree/41
do I have it right that 1.4 will make it possible to require js files like namespaces?
what do you mean?
you can already require JS files
(js/require "my-module")
or (js/require "./path/to/module")
oh that’s a different thing
the Node module support that shipped with 1.9.518 is about converting CommonJS modules to Goog modules
that’s about compiling ClojureScript projects
Lumo supports require
out of the box because it’s based on Node
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 🙂
yep, this stuff is confusing
to give more context on the classpath thing, my objective is to roughly have the same API as clojure.java.classpath
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 😉) fall into place
or we make the entire JS community need to depend on Maven
and someone will write a Maven resolver in JS
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.
ah interesting
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" 🙂 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:
root@40e572647543:/# time ./lumo -e :foo
:foo
real 0m0.113s
user 0m0.100s
sys 0m0.010s
that’s 113ms
I don’t know how it’s faster in my Ubuntu Docker image than it is on my mac
awesome @anmonteiro !
There was an idea here to use GWT java to js converted in aether, nobody has done it yet, but it is possible 😀
yeah it’s consistently around 160ms on my mac, but 110-115 on Ubuntu
thanks!
I like to call it “environment” now 🙂
it’s not just a REPL anymore