Mantri v0.2.0 released

The new release of Mantri brings a big build flow overhaul and a lot of new goodies. It all started by what at the time seemed like a simple task, enabling multiple Built-Modules... Three months and thousands of lines later i am amped to announce the release of v0.2.0!

Here's The big picture, what's new and changed:

Can now build multiple modules into Build-Modules.

Mantri now supports Source Maps.

You can now include and use any Closure Library module, use the closureLibrary key.

key. Renamed keys in the mantriConf.json file.

file. Changed format of outputWrapper , now uses Closure's pattern.

, now uses Closure's pattern. Mantri Web component has been published on Bower as mantri .

The reason for starting works on 0.2.0 was the request to enable multiple module building. That's a well known technique, were you break up your code into isolated modules which get build separately. At load time, only your tiny core module is loaded, resulting in faster page loads. After page load, the core can lazy-load the isolated modules. The compiled (minified) result of those isolated modules, is what a Built-Module is.

Breaking up your code into multiple Built-Modules is an advanced and engaging process. You should consider if the ~300ms gain is worth the effort and resources required to maintain this workflow. If you are all in, jump into the Building Multiple Modules guide.

If you want to dig deeper into the principles upon which Mantri's multiple Built-Modules were implemented check out the "Writing Modular Javascript REWIND" article, were Built-Modules are explained in depth along with Modular Application Patterns.

In v0.2.0 Mantri introduces Source Maps revision 3. To properly implement this feature the Vendor Libraries had to be included in the, now single, compilation pass.

Enabling Source Maps is as easy as defining the location to save the file using the build.sourceMapFile option in your mantriConf.json . Read more about working with Source Maps in this article.

It's silly how Mantri wraps around Closure Tools but did not provide an option to require Modules from the Closure Library. Well, now you can do that in two easy steps:

Fetch the Closure Library source: git clone https://code.google.com/p/closure-library/ Define the location of the closure library in your mantriConf.json file:

{ "closureLibrary" : "closure-library/" }

That's it! From here on you can require any one of the hundreds of amazing modules Google has to offer. All you need to do is require the module you need and it'll be available in the global namespace:

goog.provide( 'app.util' ); goog.require( 'goog.string' ); app.util.contains = function (string, test) { return goog.string.contains(string, test); };

It is well worth your 5' to check out the categories and specific topics the Closure Library Modules cover, there are many hidden gems in there.

The v0.2.x series brings some rather breaking changes when migrating from 0.1.x. For the majority of the use cases the transition will be smooth, as there are deprecation warnings but old config files will get parsed. Until the 0.3.x series that is.

The only really breaking change is the outputWrapper option. Because of Mantri's build flow overhaul, this option is now handled by the GCC and no longer is parsed by Underscore's template.

Read the Migration guide if you are using 0.1.x.

One of the most significant changes in the built flow is the way the Vendor Libraries are bundled. In the previous series, 0.1.x, Mantri concatenated all the 3rd party libs and passed them through Uglify. Now, in the 0.2.x series Vendor Libraries along with your application are compiled all together using the Google Closure Compiler (GCC).

Here is a break down of how Mantri builds your application:

Validates all the parameters of your mantriConf.json file, Grunt task directives or CLI options...

file, Grunt task directives or CLI options... Collects all the Vendor Libraries in an array, sequenced.

Will run the Closure Builder tool to resolve the dependency tree of your application and generate the list of files in the order they should be bundled.

Will concatenate the Vendor Libs array to the Application's array and create the master array of files to compile.

Configures and executes the Google Closure Compiler (GCC). If multiple Built-Modules are defined, Mantri will loop through them and compile each one as per the directives.

If Source Maps are enabled, a directive will be appended to the build file to instruct the browser where to locate the sourceMap file.

Generate some stats for you.

There are more than meets the eye in the stats generated. One of the secret powers of the Google Closure Compiler (GCC) is that there is a gzip optimization layer among the multiple passes. That means GCC produced bundles have greater compression ratios when gziped!

With this version of Mantri, the latest builds of GCC and Closure Builder have been packed. Tons of optimizations and tweaks by Google Engineers for free!

Thank you all for your feedback and interest in Mantri! Please share your experience with Mantri and the how the new version works for you!

Thank you!

Please enable JavaScript to view thecomments powered by Disqus.

Disqus