@hypirion: how is the inclusion order in lein by lower version? say I have tools.reader 1.0.0-alpha3 and tools.reader 0.8.4 imported because transitive, who wins?

and how to force using a version?

Oh I read the FAQ but one version of tools.reader is imported by a plugin, does it win over :dependencies?

:dependencies [[org.clojure/tools.reader "1.0.0-alpha3"]
                 [org.clojure/clojure "1.7.0"]
                 [org.clojure/clojurescript "1.7.228"]
                 [com.cognitect/transit-cljs "0.8.220"]]

actually maybe yes, it might be a cljsbuild problem, sorry for the noise

@richiardiandrea: Oh, no worries. If you depend on a dependency directly, that version will almost always be picked. The algorithm used is known as nearest wins: It will generally pick the version closest to the root in the dependency tree. If there are multiple versions in the same distance from the root, the first one in the dependency vector is picked. For example, say we have the dependency vector

:dependencies [[A "0.1.0"]
               [E "1.0.0"]]

|-- A 0.1.0
|   |-- B 0.1.1
|   |-- C 1.0.0
|       |-- F 0.2.1
|
|-- E 1.0.0
    |-- B 0.2.0
    |-- F 0.3.0

:dependencies [[E "1.0.0"]
               [A "0.1.0"]]

(The only case where this isn't followed strictly is when there are version ranges somewhere, and when that happens noone really understands what you get back. Fortunately version ranges doesn't seem to be that popular in libraries used by Clojure developers.)

I guess that was a bit more than you asked for, but I found it helpful to understand how that piece of magic works so I guess more people would, too.

@hypirion thanks!! That explains a lot, BTW. I opened a PR: https://github.com/emezeske/lein-cljsbuild/issues/439

...from what I see cljsbuild does not touch dependencies which are the ones in the class path at the moment of the build..digging digging...but maybe it's more like a lein problem