ClojureScript

Details

Type:
Enhancement

Status:
Closed

Priority:
Trivial

Resolution:
Declined

Affects Version/s:
None

Fix Version/s:
None

Component/s:
None

Labels:

None

Description

Right now, adding JavaScript dependencies to a ClojureScript project is doable, but more difficult than it should be. Even assuming the use of lein-cljsbuild, one must always add appropriate :libs and/or :foreign-libs and/or :externs options to each build invocation...not just once (e.g. when packaging a JavaScript library as part of a ClojureScript library), but in every situation where such dependencies are used.

Addressing this for foreign libs is probably not practical, but we should be able to extend the treatment of goog.* dependencies (embodied in cljs.closure/goog-dependencies*) to any Google Closure-ready JavaScript library/module. In short, this would look like:

1. At load-time in cljs.closure, scan the classpath for all .js files
2. Use parse-js-ns to obtain each JavaScript file's provides and requires.
3. Include the resulting maps in js-dependency-index.

The end result should be that, if a JavaScript file is on your classpath that contains e.g. goog.provide('foo.bar');, you can use it simply by adding (:require [foo.bar]) to an ns declaration, without touching any build configuration.

Sound sane? Not sure if it'll work or not, but if it does, it'd make packaging and use of JavaScript libraries from ClojureScript much easier IMO.

I'll see what I can do to drum up interest and such (though I get the distinct impression that very, very few people are actively trying to use JavaScript libraries as dependencies, as opposed to "simply" vendoring them into their apps).

Anyway, in the meantime, I downgraded the priority to 'trivial', since there's an easy workaround (as described in my previous comment and documented e.g. here).

Chas Emerick
added a comment - 03/Jul/13 9:32 PM I'll see what I can do to drum up interest and such (though I get the distinct impression that very, very few people are actively trying to use JavaScript libraries as dependencies, as opposed to "simply" vendoring them into their apps).
Anyway, in the meantime, I downgraded the priority to 'trivial', since there's an easy workaround (as described in my previous comment and documented e.g. here).

I don't have strong opinions about this. This another ticket that needs some feedback from users. Perhaps ask people on the ClojureScript mailing list to try this out and find out if it addresses pain points? Thanks Chas.

David Nolen
added a comment - 03/Jul/13 7:59 PM I don't have strong opinions about this. This another ticket that needs some feedback from users. Perhaps ask people on the ClojureScript mailing list to try this out and find out if it addresses pain points? Thanks Chas.

This definitely works, and it's remarkably easy. All the pieces are already there (I hadn't grokked exactly what was going on with the existing classpath scanning for named :libs and such). You can see the behaviour that would apply right now by adding :libs [""] to your build config; the criteria being used now is that the string in :libs is the prefix of the classpath entries that are found and used automatically.

Chas Emerick
added a comment - 19/Jun/13 2:11 PM - edited This definitely works, and it's remarkably easy. All the pieces are already there (I hadn't grokked exactly what was going on with the existing classpath scanning for named :libs and such). You can see the behaviour that would apply right now by adding :libs [""] to your build config; the criteria being used now is that the string in :libs is the prefix of the classpath entries that are found and used automatically.