Fork me on GitHub

does the Clojure runtime have access to the aliases that were passed? Can my code access this information somehow?


There are some system properties set. I think only clojure.libfile


Why do you need to know?


I’d like to know whether its a figwheel run or not


@stathissideris everyone is going to name their Figwheel alias differently. I'd check if the namespace is loaded/can be required, and depending on context, check if the state var is bound.


Your code might work with some lein setups too that way


good point about about naming, but I need this for my specific setup, I’m not making a generic tool, so hardcoding it would be ok


Is is possible to combine -e and -m to inject a var maybe?


I do this in edge using :jvm-opts


Jvm opts compose, main opts do not.


Using -D in jvm opts that is.


oh thanks, I’ll check it out


I think there's a NPE in t.d.a:

Error building classpath. nil
        at clojure.lang.MultiFn.invoke(
        at clojure.lang.PersistentVector.reduce(
        at clojure.core$reduce.invokeStatic(core.clj:6827)
        at clojure.core$reduce.invoke(core.clj:6810)
        at clojure.lang.RestFn.applyTo(
        at clojure.lang.Var.applyTo(
        at clojure.core$apply.invokeStatic(core.clj:665)
        at clojure.main$main_opt.invokeStatic(main.clj:491)
        at clojure.main$main_opt.invoke(main.clj:487)
        at clojure.main$main.invokeStatic(main.clj:598)
        at clojure.main$main.doInvoke(main.clj:561)
        at clojure.lang.RestFn.applyTo(
        at clojure.lang.Var.applyTo(
        at clojure.main.main(
this may be time sensitive as I'm using a just-deployed coordinate.


org.webjars.bower/react {:mvn/version "15.4.2"}
  org.webjars.bower/es6-promise {:mvn/version "4.0.5"}
  org.webjars.bower/fetch {:mvn/version "0.9.0"}
  org.webjars.bower/graphiql {:mvn/version "0.11.11"}
  org.webjars.npm/graphiql-subscriptions-fetcher {:mvn/version "0.0.2"}
  org.webjars.npm/subscriptions-transport-ws {:mvn/version "0.8.3"}
these are the deps I just added


org.webjars.npm/graphiql-subscriptions-fetcher {:mvn/version "0.0.2"} this appears to be the exact problem dep

Alex Miller (Clojure team)13:02:28

runtime does not have access to the aliases that were used @stathissideris


@alexmiller thanks, I ended up using -D to indicate the alias via properties as @dominicm suggested

Alex Miller (Clojure team)13:02:59

I can repro the npe, will take a look. shouldn’t be timing-related

Alex Miller (Clojure team)13:02:22

there’s a version range in the transitive deps, wouldn’t surprise me if that’s involved


that seems more likely, yeah. I was worried that we'd caught maven in an inbetween state and it was causing an NPE.

Alex Miller (Clojure team)13:02:11

I think it’s finding no matches in the version range

Alex Miller (Clojure team)13:02:40

so code could definitely be tightened up around that to not npe but it will just not find the dep then


yeah. makes sense. webjars is a bit weird like this I guess 🙂


I can add explicit graphiql dep here.

Alex Miller (Clojure team)13:02:29

org.webjars.npm/graphiql-subscriptions-fetcher {:mvn/version "0.0.2"} depends on org.webjars.npm/graphql {:mvn/version "[0.9.1,0.10)" but I don’t see anything older than 0.10.1 in maven central


webjars is a bit weird. You basically are deploying npm things. So if nobody has deployed graphiql 0.10, then it won't be there.


adding an explicit graphiql dep hasn't helped though, annoyingly. So I guess I will deploy 0.10 via

Alex Miller (Clojure team)13:02:39

does npm actually have jars in it?


webjars takes stuff from npm, and puts it in a jar

Alex Miller (Clojure team)14:02:28

tdeps could have an extension to use webjars directly


do you mean npm directly? I don't know how you'd use webjars directly 🙂


but either way, that would be a huge +1 from me

Alex Miller (Clojure team)14:02:35

well, you would need to tell me more things for me to understand what’s possible, but anything that can be a source of named, versioned artifacts is a potential target


good question, admittedly I don't fully understand how webjars works.

Alex Miller (Clojure team)14:02:17

well, webjars seems to have a a cdn? whatever step you’re doing seems like some sort of mindless wrapping task

Alex Miller (Clojure team)14:02:21

programs are good at those


> All of the WebJar contents are available on the public jsDelivr CDN. Just prefix //{groupId} in front of your static asset URLs. For instance, if using the org.webjars : jquery WebJar and your local URL to jquery.js is /webjars/jquery/2.1.0/jquery.js then the CDN URL would be: // So I guess the contents of the jars are available via the CDN, rather than the jars themselves.


the actual jars go to maven.


then you can request a new jar to go to maven via clicking buttons on - that triggers an automated process

Alex Miller (Clojure team)14:02:11

“clicking buttons” :)


is your proposal that instead of deploying to maven, a webjars-like thing would build the jars and stick them in ~/.local/cache/webjars/ ?

Alex Miller (Clojure team)14:02:47

why do you even need jars? they’re just files on the classpath right?

Alex Miller (Clojure team)14:02:39

it would be helpful to do something that actually helped people down the line as they build and deploy stuff

Alex Miller (Clojure team)14:02:08

I am too ignorant about cljs / npm / node / etc to not know what would be useful


you're right. jars not needed.

Alex Miller (Clojure team)14:02:58

npm is a central repository. it has stuff you want in your app. tools.deps has an extension point to plug in code to get stuff and put it on your classpath (and determine its dependencies)


fwiw, this is pretty unrelated to cljs.

Alex Miller (Clojure team)14:02:09

see how ignorant I am? :)


I think npm is a good target for t.d.a. So is bower.


maybe not bower, it's kinda old now.

Alex Miller (Clojure team)14:02:13

yeah, anything that didn’t come out this month in js is old :)

Alex Miller (Clojure team)14:02:14

I guess coming back to a problem statement - this is like js stuff that you want to serve as static resources from your app?

Alex Miller (Clojure team)14:02:10

does npm really not have any kind of namespacing?

Alex Miller (Clojure team)14:02:44

oh, it has scopes, I see

Alex Miller (Clojure team)14:02:40

well, seems like the info necessary exists if you want to file a ticket defining what’s useful


> I guess coming back to a problem statement - this is like js stuff that you want to serve as static resources from your app? Exactly!


Although, admittedly, I'd personally be quite happy with cdn integrations.


bower predates npm afaik. It was a big step forward at the time, but it's not really used. npm got more traction and was dominant by the time a majority of companies turned their attention to js.


bower doesn't recommend you use bower so ¯\(ツ)


I'll write down that I want to create this, and have a note for myself to think a little more about what I want 🙂


@alexmiller while I have you, is there a workaround for this graphiql issue? bintray appears to be having issues, and I can't get an older graphiql to deploy. :exclusions hasn't worked, nor has an explicit graphiql dependency on 0.11.11.

Alex Miller (Clojure team)14:02:37

not sure I have a good option for you

Alex Miller (Clojure team)14:02:34

if you made webjars deploy version 0.9.1 to maven central that would let it proceed


Unfortunately, that's failing 🙂 I thought you might say that though. It's okay

Alex Miller (Clojure team)14:02:09

kind of an interesting failure mode. would be better if it could defer long enough to be overridden

Alex Miller (Clojure team)14:02:56

in this particular case, the only reason it’s resolving early is due to the version range I think, trying to narrow that down to single version


Hmm, 0.9.1 now exists, but I'm still seeing a NPE. no it doesn't, i've been deploying the wrong package


graphiql vs graphql


You hit an NPE whenever you have a transitive dependency which doesn't exist. I'm seeing it with a version pinned to [1.0.3] (maybe that is a range though?)


Actually, no. I'm confused.


I've rm -rf .cpcache, and used -Sforce, just in case.


❯ clj -Sdeps '{:deps {org.webjars.npm/graphql {:mvn/version "0.9.1"}} :aliases {:v {:verbose true}}}' -A:v -Sforce
Initial deps to expand:
{org.clojure/clojure #:mvn{:version "1.10.0"},
 org.webjars.npm/graphql #:mvn{:version "0.9.1"}}
Expanding org.clojure/clojure #:mvn{:version 1.10.0}
        =>  include, pin top dep
Expanding org.webjars.npm/graphql #:mvn{:version 0.9.1}
Error building classpath. nil


[ERROR] Failed to execute goal on project my-app: Could not resolve dependencies for project : Failed to collect dependencies at org.webjars.npm:graphql:jar:0.9.1 -> org.webjars.npm:iterall:jar:[1.0.3]: No versions available for org.webjars.npm:iterall:jar:[1.0.3] within specified range -> [Help 1] maven is struggling too


Oh. Interesting. It is fine with it as a top-level dependency, but not as a transitive dep.

Alex Miller (Clojure team)18:02:32

[1.0.3] is a version range. from Maven’s perspective just 1.0.3 by itself is a specific version

Alex Miller (Clojure team)18:02:55

I don’t think there’s any difference with top vs transitive - you probably just have it in your local Maven repo at ~/.m2/repository now

Alex Miller (Clojure team)18:02:50

it works for me as a transitive dep, and as a top-level dep with specific version, and as a top-level dep with version range [1.0.3]

Alex Miller (Clojure team)18:02:59

(clearing all caches before each one)

Alex Miller (Clojure team)18:02:53

$ rm -rf ~/.m2/repository/org/webjars
$ clj -Sdeps '{:deps {org.webjars.npm/graphql {:mvn/version "0.9.1"}}}' -Sforce
Downloading: org/webjars/npm/graphql/0.9.1/graphql-0.9.1.pom from 
Downloading: org/webjars/npm/iterall/maven-metadata.xml from 
Downloading: org/webjars/npm/iterall/1.0.3/iterall-1.0.3.pom from 
Downloading: org/webjars/npm/graphql/0.9.1/graphql-0.9.1.jar from 
Downloading: org/webjars/npm/iterall/1.0.3/iterall-1.0.3.jar from 
Clojure 1.10.0

Alex Miller (Clojure team)18:02:21

when you deploy to Maven central it can take 10 minutes to an hour to show up for download, so maybe it just wasn’t there yet


I'm a bit suspicious that perhaps version ranges are searched somewhere different than specific versions.

Alex Miller (Clojure team)18:02:24

but there is an extra piece of code to explicitly resolve them in tdeps

Alex Miller (Clojure team)18:02:09

if you haven’t, you should try selectively deleting part of your ~/.m2/repository/org/webjars/…

Alex Miller (Clojure team)18:02:32

there are metadata files about versions that are cached there and only updated once every 24 hrs

Alex Miller (Clojure team)18:02:55

(this is a setting we don’t currently surface - if you’re using mvn, you can pass -U to force an update)


Is it possible that metadata would store [1.0.3] separately from 1.0.3?

Alex Miller (Clojure team)19:02:19

it just stores known versions and then uses that to resolve

Alex Miller (Clojure team)19:02:41

but if you had already filled that cache for the day and the repository said that version didn’t exist, it’s going to keep telling you that

Alex Miller (Clojure team)19:02:51

it will not go re-check the repository

Alex Miller (Clojure team)19:02:37

this file in particular: ~/.m2/repository/org/webjars/npm/iterall/maven-metadata-central.xml

Alex Miller (Clojure team)19:02:46

last check timestamps are in ~/.m2/repository/org/webjars/npm/iterall/


@alexmiller on the slow REPL startup of the latest java 8 (u202) on Linux, looking at the stack traces, it spends a lot of time compiling some java-time things ( One CPU goes to 100% during this and after that stack trace is gone, the REPL starts.


java-time does lot of meta programming stuff, finding types, doing a graph traversal to find paths between types


so I could imagine types changing between jdk versions


blugh, after all this work, one of my transitive deps doesn't work because it has a custom gql license which webjars won't automatically repackage because it doesn't recognize. If we were a direct npm client this would be avoided. Very tempting proposition really.


@alexmiller if I wrote an npm client with an EPL license in clojure, would it be candidate for use in t.d.a? Or would you prefer it was under the clojure/core umbrella?

Alex Miller (Clojure team)20:02:38

could be an external lib (we use others already). I think there are some out there already. but maybe the amount of access needed by tda is so small to not even be worth that, not sure.

Alex Miller (Clojure team)20:02:40

I guess you probably want a cache ala tools.gitlibs though and that’s something we’d want outside tda


I haven't really looked at the npm client details yet. Might be worth seeing if we can share the yarn cache. Plus I'm a bit uncertain about how to handle http.

Alex Miller (Clojure team)20:02:07

well I think you have the same options as gitlibs - shell out to npm or make a direct implementation

Alex Miller (Clojure team)20:02:07

pros and cons. might be worth gathering some more information about the things you need to implement: 1) given a name/version, determine that lib’s deps (don’t need transitive, just shallow) 2) given a name/version, download the bits somewhere


Npm is far more amenable I think. Yarn is a reimplementation of the npm client. Plus, npm doesn't have a global cache, and because of the hierarchical nature, you probably want more control.


I suppose you have to figure out auth, which is the recurring issue.

Alex Miller (Clojure team)20:02:01

well public stuff is fine I assume

Alex Miller (Clojure team)20:02:22

for creds, we already have a means to do this via the maven settings.xml on a per-repo basis

Alex Miller (Clojure team)20:02:43

admittedly kind of weird to put npm auth there


@hiredman, the weird thing is that it's only a minor version upgrade (from 8.u192 to 8.u202). With 192 the repl starts in seconds, with 202 it takes minutes


I know it's aside from your problem @stijn but I wouldn't use that library, to be perfectly honest.


java.time is perfectly approachable

dominicm20:02:03 makes java.time quite nice, and it works in cljs :face_with_rolling_eyes: (I work for JUXT)


That's a matter of opinion @U050ECB92 🙂 I find really does produce cleaner-looking code in a lot of situations.

ghadi21:02:40 seems to have a steep cost in classloading and metaprogramming


It's a one-off cost, the first time you use certain constructors. It's fast after that.


The readme even shows how you can "warm up" that stuff.


I was a bit surprised that it caused such a "blip" on 202(?) since it's fine on 192 (and on subsequent builds) according to the OP.


I will investigate some more when I have the time. For now, went back to 192.


the actual JDK package java.time


maybe check to see if you have org.threeten.extra.Temporals and or org.joda.time.DateTime on your classpath, and if calling (Class/forName ...) with those class names changes behavior on the different jdk versions


yes org.joda.time.DateTime is on the classpath. will check later what the impact is

Alex Miller (Clojure team)20:02:36

just a couple small enhancements, no biggie


Woah, very quick, thanks!

Alex Miller (Clojure team)20:02:55

hadn’t released in a while


That Groups post hasn't gone out via email again, as far as I can see @alexmiller


(I just replied to it on the web which should cause it to be seen via email 🙂 )

Alex Miller (Clojure team)22:02:52

I sent that one from a different account