Last active
August 29, 2015 14:13
-
-
Save swannodette/0eaf17815d49b7b77a95 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
{: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}}}}} |
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@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.