A while ago I was banging my head against http://webjars.org/ and the deployment strategies in use there, in particular I mentioned that the build takes a very long time.
(link: ~alexmiller) suggested that the builds could be happening locally on your machine. This is good for 2 reasons:
- Faster
- No licensing issues with reuploading (webjars will sometimes have broken dep trees because of this)
The problem being solved is that often you want a versioned asset like jQuery or Bulma.io (css framework), but you don't want to just dump the whole asset into your repo because that would make it harder to update.
I don't think we should isolate ourselves to just the built files though, as it's still useful to bring in something like bulma to use it's sass files as part of a compilation pipeline. But sometimes you just want the default build and that's okay too.
WebJars seems to support multiple versions of the same asset on the classpath at once, there are two mechanisms related to this:
- The path is something like webjars/jquery/1.2.0/foo.js
- A WebJarLocator which can find these on the classpath without knowing the version (I believe it looks for a manifest file at a known location).
I'm only thinking of server-side use (because that's my primary use-case), but recently I have been using clojurescript with npm dependencies, and I feel that it would be very useful to specify dependencies for clojurescript in the same way.
npm is a good target for support in tools.deps:
- It's built with an api from the ground up. Yarn (an alternative npm client from Facebook) has been very popular building on top of the api
- Almost everything in the front-end world gets uploaded there. There are older repos like http://bower.io/ which are sometimes in a more convenient format, but npm has seen the highest adoption
