cljs_modules.clj

{:optimizations :advanced
 :output-dir "./target/client/production/"
 :cache-analysis true
 :output-modules {
  {:id :common
   :out "./resources/assets/js/common.js"  
   :entries '#{com.foo.common}}
  {:id :landing
   :out "./resources/assets/js/landing.js" 
   :entries '#{com.foo.landing}
   :deps #{:common}
  {:id :editor
   :out "./resources/assets/js/editor.js"
   :entries '#{com.foo.editor}
   :deps #{:common}}}}}

I went down the path you are on right now, in Theory it is fine. It just didn't work out so well in practice.

• Computing dependencies works until you run into the edge case I described
• "Matchers" (I used regexp) didn't offer much value over explicit namespaces. Say module-b uses cljs.core.async, why do I need to add a "matcher" for that if I can derive this information (dependency graph) by looking at the :main (entry point) of module-b. In practice "matchers" just were way too explicit.

I don't think mori is a good example use-case for modules since it is far too simple.
Not sure if this is what you had in mind, but when I run it through shadow-build I end up with:

  12K mori.chain.js
 189K mori.js
 1.3K mori.mutable.js
 7.9K mori.reducers.js
 6.2K mori.zip.js

With gzip

 2.3K mori.chain.js.gz
  41K mori.js.gz
 644B mori.mutable.js.gz
 1.7K mori.reducers.js.gz
 1.6K mori.zip.js.gz

https://github.com/thheller/mori/tree/shadow-build
run lein run -m build/release

Given these tiny sizes for "addon" modules it is probably more overhead to have an extra request fetching these than just serving them at all times. But I'm not familar with mori, maybe I'm missing something.

https://github.com/thheller/mori/blob/shadow-build/dev/build.clj#L22-L26
Note that I only entered application specific information (ie. mori.*), implementation details (cljs.core) ended up in the correct places.

https://github.com/thheller/mori/blob/shadow-build/release/manifest.json
The manifest contains an overview which sources ended up in which module.

I'm not going to say that my solution is perfect or better in any way, just trying to make it clear which problems I faced so you might skip over them. You probably have a different view on things, which is good. Definitely going to watch what you come up with.

@theller the Mori metrics feedback is great thanks! My intent was to remove everything from Mori except for the collection functions. But I suppose since all modules are compiled together this won't prevent the shared module from being quite large. But this isn't a problem with "matchers" per se it's a problem with having a monolithic core. Still I see your point. We'll drop matchers for now.

UPDATE: It appears Google Closure supports code motion between modules under advanced optimizations. Still, I think dropping "matchers" is fine.

RE: computing module dependencies I suppose if Google & you have gone down this path you're probably aware of the pitfalls.

Updating the proposal.

Quick question on the current proposal - are entry points purely for the purpose of computing dependencies (ie entry points for the dependency graph, not for execution)?

Besides that, it looks good to me.