In a Browser environment it is sometimes desirable to split the output of a Google Closure optimized build into multiple files (modules) instead of one. This is an optimization and has no other uses beside that. On traditional Web Pages it is very common that not all code is required on all pages, therefore it makes sense to split code into logical groups and only load what is required on each page. Doing this manually would be hard (impossible) due to the aggressive renaming of the Closure optimizer, therefore it needs to be setup before Closure Compiler is invoked.
The result of a compilation with only one defined module is identical to compiling without modules, it can therefore be the default to compile with modules.
Need a good one, they are almost always app specific.
- Module - Given the set of all available Inputs, a module represents a subset of those. A Module can depend on other Modules, but any Input may only appear once in the entire compilation of the Graph.
- Main (?) - A namespace that represents an entry point to the application. These either contain public (exported) API functions or code that is executed when loaded.
Let the user define each Module and their Main namespaces. It would be desireable to get the resulting dependency graph from this information, otherwise the user needs to supply the dependency info as well.
A sample implementation can be found at: https://github.com/thheller/shadow-build
Since the cljs.closure namespace assumes to create only one output file, the shadow-build library is basically a complete reimplementation of it with some features added. When writing it I (Thomas Heller) opted to go with a "no shared state" approach meaning that I carry the state of the compilation around with me as a immutable map. This map is created and modified in multiple steps during a compilation. Steps usually follow this flow:
Configuration -> Discovery -> Module Definition -> Compilation -> Output
The generated manifest.json can be used by additional tooling but is not needed at runtime. In production I timestamp each module with a custom compilation step (https://gist.github.com/thheller/6c3ad4c880b035921ce6) and the manifest.json contains the mapping of module name -> filename. A server side component then watches the manifest and reloads it, the information of the manifest is then used to emit the correct <script src="..."> tags in the HTML. The code just refers to a module by name, the actual filename is resolved automatically.