jQuery Plugins and Closure-Compiler - Web Strategy and Development News

Closure-Compiler provides impressive minification and optimization on your JavaScript. However, not all code compiles equally. I recently worked on converting the jQuery Tooltip Plugin to be compatible with the ADVANCED_OPTIMIZATIONS mode of the compiler. This process went smoothly for the most part, but there were a couple of tricky points along the way.

Step 1: Make the plugin compliant with the jQuery plugin style guidelines

On my first attempt I converted the plugin without doing this and had a lot more difficulty. This step alone saved quite a few hassles. The tooltip plugin is for the most part well written, but doesn’t match the latest version of the style guidelines. Mainly it just ran afoul by defining more than one namespace. Moving the internal helper functions out so they weren’t defined as prototypes took care of this.

Step 2: Strongly typed settings

As with many jQuery plugins, the Tooltip Plugin takes an optional settings object literal with configuration options. Within the tooltip functions, we don’t want the compiler to rename those properties and we want them to be strongly typed. The easiest way to accomplish this was to make an extern file for the plugin. Extern files serve two purposes: they allow you to define strong types that are external to your code and they prevent the compiler from renaming properties.

The jQuery Tooltip Extern file defined both the jQuery.tooltip namespace and a settings object type and associated properties. Now I can use the settings object in the tooltip code without worries of it being renamed.

Step 3: Add JSDoc annotations

To get the most out of the compiler, I added JSDoc annotations to the internal functions and variables. When compiled, this raised a few areas of concern.

Unknown properties renamed

The tooltip plugin gets and sets a few expando properties (such as tooltipText) on anchors by using “this.tooltipText = ‘content'” notation. While this is perfectly legitimate javascript, the compiler is free to reduce that property name to something like “this.a=’content'”. To prevent this behavior, I switched to reading and assigning these custom properties either used the jQuery attr method or the javascript getAttribute/setAttribute functions. Since the unknown properties are in strings, the compiler leaves them alone.

Inconsistent types

In some cases, the compiler warned that a function returned a type that was different than expected. Functions like jQuery.data return generic Objects. Since I know what type to expect (my tooltip settings type), I had to typecast the return to silence the warning.

return /** @type {jQuery.tooltip.settings} */ (jQuery.data(elem, 'tooltip'));

External plugin detection

The Tooltip Plugin will use the functionality of the bgiframe plugin if it is included. It checks for the existence of the plugin by checking for it’s prototype by name:

if($.fn.bgiframe)

Since the compiler doesn’t have a definition of the bgiframe prototype, it renames the property. To prevent this behavior, I switched to quoted syntax using strings:

if($.fn["bgiframe"])

Step 4: Testing

Of course, I made a couple of copy/paste errors and had a stray comment or two. Thankfully the compiler is excellent at checking for these errors and provides good error messages.

The harder part is always the runtime checking. Since debugging the minified code is a migraine waiting to happen, I make good use of the –debug and –formatting PRETTY_PRINT flags. This makes it very easy to match the compiled code up to the original and see where any final issues lie.

The Final Product

I can now use all of my source files to produce a minified version. Here’s the final compilation command:

java -jar compiler.jar --compilation_level ADVANCED_OPTIMIZATIONS --warning_level VERBOSE --externs jquery-1.5.externs.js --externs jquery.tooltip.externs.js --js jquery.tooltip.js --js_output_file jquery.tooltip.min.js