ClojureScript

Automatically scan the classpath for non-goog JavaScript libraries

Details

  • Type: Enhancement Enhancement
  • Status: Closed Closed
  • Priority: Trivial 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.

Activity

Hide
Chas Emerick added a comment - - 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.

Show
Chas Emerick added a comment - - 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.
Hide
David Nolen added a comment -

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.

Show
David Nolen added a comment - 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.
Hide
Chas Emerick added a comment -

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).

Show
Chas Emerick added a comment - 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).
Hide
Chas Emerick added a comment -

This is subsumed by CLJS-656, closing.

Show
Chas Emerick added a comment - This is subsumed by CLJS-656, closing.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: