I saw this initiative, but I hardly imagine a Github repo/organisation managing the whole infrastructure. As you said: we have clojars and maven.
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. After all, I think, your example of react packaging https://github.com/swannodette/react-cljs is clean and simple enough. понедельник, 26 января 2015 г., 1:42:54 UTC+6 пользователь 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 > <javascript:>> 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 >> написал: >> >>> 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 >>> >>> -- >> 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 >> <javascript:> >> 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 <javascript:> >> 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 <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
