Thomas, First thank you for starting this project!
I recently joined a team at Atlassian that uses ClojureScript to support collaborative editing. I don't think I need to sell the community here on the advantages of ClojureScript, but I think packaging still needs work. If you use ClojureScript for your entire UI you probably don't have any issues, but in larger organizations we need to "Play as a Team." It does not seem feasible or reasonable to expect that other teams switch to using the ClosureScript compiler and make their js libraries play nice with closure because the end result will be marginally better, especially given the work involved in ensuring they still work with advanced optimizations may be non-trivial. The only practical alternative I'm currently aware of is to precompile the ClojureScript with optimizations and have them include this as a script tag in their page. The disadvantages of this are many: * separate download - not bundled with other js libraries * not commonjs / cannot require / pollutes global namespace * install/upgrade/versioning process is different / change script tag rather than npm/yarn * each precompiled ClosureScript library will include closure and cljs again As we add support for multiple editors I want to split the library into multiple artifacts that can be released separately, however that last bullet point is undesirable. I have had some success in adding a cljsbuild along side a webpack build, but CommonJS has solved a lot of pain points for JS devs and most modern js devs now expect an npm artifact. Although shadow-cljs doesn't solve having different install/version process it does appear to solve the other issues and is better than using a script tag. I did have a general question though. I understand that if you compile multiple ClosureScript libraries independently each will end up with duplicate bits of closure and cljs core. Shadow-cljs, as I understand it, appears to solve this by first compiling all the ClosureScript code together and exposing it as a commonjs module. But thinking out-loud here...isn't sharing dependencies the problem npm is trying to solve? could we leverage that instead of reinvent it? What if google closure libraries and cljs.core were published as their own commonjs npm libraries - precompiled but not minified yet? Couldn't cljs libraries then just 'require' them without resulting in another copy or requiring the closurescirpt compiler (and jvm)? In my ideal world, I think I would be able to specify :npm-module as the clojurescript compiler target and it would generate js that can be packaged in npm that 'requires' rather than bundles cljs and closure. Minification can be done downstream with *all* the javascript, not just the cljs code. I also found a closure plugin for webpack https://www.npmjs.com/package/webpack-closure-compiler (I never used it though), so maybe we can still get just as good if not better results doing it later? I'm not sure what would be involved in rewriting cljs output to require "require" closure and cljs.core as their own libraries, but maybe the partially solved already with https://github.com/clojure/clojurescript/wiki/JavaScript-Module-Support-(Alpha)? Thanks! -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/clojurescript.
