ANN: ClojureScript 0.0-2719, JavaScript Dependencies

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

New release version: 0.0-2719

Leiningen dependency information:

    [org.clojure/clojurescript "0.0-2719"]

ClojureScript is not an island, like Clojure on the JVM, ClojureScript

embraces the many benefits provided by the host. However this goal

has been hampered by another goal - the compilation stragey. Google

Closure Compiler offers superior optimization and minification for

ClojureScript while simultaneously making it considerably more

difficult to integrate non-Closure compatible libraries. Using popular

libraries like jQuery, React or D3 is an error prone process: "which

extern did I forget?", "which script tag did I miss for development?",

"are these script tags in dependency order?".

No more. 0.0-2719 delivers full support for non-Closure compatible

libraries through some less known features that have been lurking

around for almost three years - `deps.cljs` and the :foreign-libs

compiler option.

`deps.cljs` is a simple EDN file provided at the root of a JAR that

describes additional build information for the ClojureScript

compiler. For example here is the `deps.cljs` for the React JAR I

maintain:

{

 :foreign-libs [{:file     "react/react.js"

                 :file-min "react/react.min.js"

                 :provides ["com.facebook.React"]}

                {:file     "react/react_with_addons.js"

                 :file-min "react/react_with_addons.min.js"

                 :provides ["com.facebook.ReactWithAddons"]}]

 :externs ["react/externs/react.js"]

}

This file provides all the information ClojureScript needs to

correctly manage the foreign dependency for you under all compilation

modes and REPLs.

In a REPL:

   cljs.user> (require 'com.facebook.React)

   cljs.user> (. js/React 

                (renderToString 

                  (. js/React (DOM.div nil "Hello!"))))

In your project:

   (ns foo.bar

     (:require com.facebook.React))

   (enable-console-print!)

   (println

     (. js/React

       (renderToString

         (. js/React (DOM.div nil "Hello!")))))

The above works under all compilation modes. There is no need to

include React as a script tag under development, there is no need to put

script tags in dependency order, there is no need to add React to

:preamble under :advanced, and there is no need to explicitly provide

:externs.

All that is required is that JavaScript libraries be packaged in JARs

with a `deps.cljs`.

Some of you might reasonably ask why not a tool like Bower for this

instead?  Bower requires an additional dependency on Node.js. While

ClojureScript embraces Node.js as a useful target it is not a

requirement to be productive. Bower manages dependencies, but in the

Clojure world we have already embraced Maven for this task and have

done the same for ClojureScript. Finally Bower does not address the

problem of loading libraries at runtime. This is challenging to do -

some JavaScript libraries adopt CommonJS, some AMD, and the most

popular ones make no assumptions at all allowing users to simply use

script tags as they have done for nearly two decades. The above

solution addresses the issue for all ClojureScript users by

eliminating paralysis of choice. Finally none of the above

precludes Bower usage in any way whatsoever.

This new feature addresses a long outstanding pain point with

ClojureScript development. All that is required is that we take the

time to properly package up the most popular JavaScript libraries that

fill gaps not currently served by exising ClojureScript and Google

Closure Library functionality.

Please kick the tires and feedback is most welcome. This feature

touched many bits of code so there are likely to be wrinkles and we want

to get these ironed out as quickly as possible.

## 0.0-2719

### Changes

* Full support for foreign dependencies

* CLJS-985: make ex-info not lose stack information

* CLJS-984: Update Node.js REPL support to use public API

* CLJS-963: do not bother computing goog/dep.js under :none

### Fixes

* CLJS-982: Var derefing should respect Clojure semantics

* CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases

* CLJS-979: ClojureScript REPL needs error handling for the special functions

* CLJS-971: :reload should work for require-macros special fn

* CLJS-980: ClojureScript REPL stacktraces overrun prompt in many cases

* CLJS-979: ClojureScript REPL needs error handling for the special functions

* CLJS-971: :reload should work for require-macros special fn

* CLJS-936: Multi arity bitwise operators

* CLJS-962: fix inconsistent hashing of empty collections

[Bruce Hauman]

Great stuff! This will smooth things out quite a bit. 

I spent far too much time just yesterday trying to get an advanced build working right.

Thanks!

[Martin Klepsch]

David, thanks for making those improvements to Clojurescript, they'll

make things a lot easier in the future.

In the realm of Boot we started working on CLJSJS as an effort to

package up and ship popular Javascript libraries for use in Clojurescript [1].

While these packages have only been compatible with a Boot-based

Clojurescript build chain we fully intend to make them work with this

new approach to handle external Javascript libraries.

That said a bunch of libraries are already in place, we tracked down

extern files etc, so the changes to make them compatible should be

rather small. Contributions are very welcome. I hope to get one of the

libs compatible tomorrow so the migration path for the others is

clear.

A general question/concern I'd like to voice in that context is that

this change makes it hard to split JS preamble from our compiled

Clojurescript.  Given that the Clojurescript code might change on a

daily basis and the preamble mostly stays the same this forces users

to re-download our (unchanged) JS dependencies over and over again,

while caching them would have provided us with much better performance.

[1] https://github.com/cljsjs

[David Nolen]

On Sat, Jan 24, 2015 at 10:43 AM, Martin Klepsch <martin...@googlemail.com> wrote:

A general question/concern I'd like to voice in that context is that

this change makes it hard to split JS preamble from our compiled

Clojurescript.  Given that the Clojurescript code might change on a

daily basis and the preamble mostly stays the same this forces users

to re-download our (unchanged) JS dependencies over and over again,

while caching them would have provided us with much better performance.

I understand the desire/need for splitting out foreign deps but this should be addressed separately with the coming Google Closure Module support

David

[David Nolen]

On Sat, Jan 24, 2015 at 11:01 AM, Khalid Jebbari <khalid....@gmail.com> wrote:

A question (maybe stupid/obvious) : why do you need to declare the "min" version of js lib ? The normal version + the extern file is all that's needed to compress the file with the Closure Compiler, no ?

Declaring the minified version is completely optional.

JavaScript libraries generally ship minified versions so why not leverage it? Including the un-minified version into the Closure Compiler build is usually asking for trouble (I encountered problems with React in the past) and just slows down advanced builds by having more JavaScript to process, especially large libraries like React (>30KLOC).

David

[Daniel Kersten]

Thanks David for your continued hard work - another fantastic release. This looks really good and solves real problems.

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[Moritz Ulrich]

> --
> Note that posts from new members are moderated - please be patient with your first post.
> ---
> You received this message because you are subscribed to the Google Groups "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
> To post to this group, send email to clojur...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojurescript.

As I already said on IRC: This is just *great*. I tried it in both
applications I'm working on right now and both saw a (meaningful)
reduction in size.

Thanks again for this great release!

[David Nolen]

Some further explanation on packaging JavaScript libraries for ClojureScript consumption https://github.com/clojure/clojurescript/wiki/Foreign-Dependencies

[David Nolen]

I just cut 0.0-2723. The significant change is an often requested feature - that script inclusion for :none be the same as other build settings. This is finally supported if you provide a :main entry specifying a namespace.

{:main hello-world.core

 :output-to "hello_world.js"

 :output-dir "out"

 :optimizations :none

 :source-map true}

Then your markup just needs:

<script src="hello_world.js" type="text/javascript"></script>

Same as :advanced.

David

On Sat, Jan 24, 2015 at 10:10 AM, David Nolen <dnolen...@gmail.com> wrote:

[David Nolen]

And just cut 0.0-2725 to address a Node.js target support regression.

David

On Sat, Jan 24, 2015 at 10:10 AM, David Nolen <dnolen...@gmail.com> wrote:

[David Nolen]

Just cut 0.0-2727 to fix an issue around the new :main support. ClojureScript now supports an :asset-path option to control how the :main script imports other scripts in order to respect whatever asset configuration you may have set up for your web server.

David

[David Nolen]

I strongly recommend the Clojure(Script) community join forces when packaging libraries to avoid duplicated effort and dependency conflicts.

CLJSJS seems like a good initiative to me along these lines: http://cljsjs.github.io

David

On Sun, Jan 25, 2015 at 1:49 PM, Vladimir Bokov <bokov...@gmail.com> wrote:

Thanks David!

I also already packaged https://github.com/razum2um/jquery-cljs using your react repo as example

суббота, 24 января 2015 г., 21:10:29 UTC+6 пользователь David Nolen написал:

--
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com

Note that posts from new members are moderated - please be patient with your first post.

To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---

You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Nolen]

On Sun, Jan 25, 2015 at 5:40 PM, Vladimir Bokov <bokov...@gmail.com> wrote:

I saw this initiative, but I hardly imagine a Github repo/organisation managing the whole infrastructure. As you said: we have clojars and maven.

For the most popular libraries having a curated set is going to be important - Maven knobs can only do so much.

Besides, they offer a naming convention and versioning policy, which I fully agree with, but I see no need to use 'boot-cljsjs' to follow them.

CLJSJS packaged JARs will not require boot-cljs - they will package JAR artifacts with the required deps.cljs.

 

After all, I think, your example of react packaging https://github.com/swannodette/react-cljs is clean and simple enough.

And it will be deprecated as soon as CLJSJS provides their own deps.cljs packaged version.

David

[Ivan L]

To this end I would hope everyone takes a look at using webjars.org as their source for frontend libraries.  imo, it's a way forward to dep mgmt outside of bower/npm/node etc.

[David Nolen]

Webjars doesn't package JS libs in a useful way for ClojureScript.

--

Note that posts from new members are moderated - please be patient with your first post.

---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.

[Laurent PETIT]

Yet ?

--

Laurent Petit

[David Nolen]

On Mon, Jan 26, 2015 at 3:08 AM, Laurent PETIT <lauren...@gmail.com> wrote:

Yet ?

Right if Webjars was open to including the necessary information that would be great. I suspect this will be challenging since Webjars has chosen RequireJS as the runtime loading mechanism whereas deps.cljs provides Google Closure runtime dependency information for a specific compile to JavaScript language.

Likely the most promising way to integrate Webjars is to extract Google Closure information from the RequireJS file located in RequireJS supporting JARs. This processing could be performed by other tools like cljsbuild.

Still I have concerns about ClojureScript discoverability and Webjars - "is this Webjar fully ClojureScript compatible?".

David