Unwrapping redundant IIFEs

[Rich-Harris]

In my library I have many small modules that are used often, like this:

utils/isNumeric.js

define( function () {

  'use strict';

  // http://stackoverflow.com/questions/18082/validate-numbers-in-javascript-isnumeric
  return function ( thing ) {
    return !isNaN( parseFloat( thing ) ) && isFinite( thing );
  };

});

After it's been through r.js and amdclean, it looks like this:

var utils_isNumeric = function () {

        return function (thing) {
            return !isNaN(parseFloat(thing)) && isFinite(thing);
        };
    }();

In this case, there are no dependencies, and no variable declarations - just a single return statement. So it could be rewritten like this:

var utils_isNumeric = function (thing) {
  return !isNaN(parseFloat(thing)) && isFinite(thing);
};

I think this is probably quite a common case in libraries that use AMD for internal code organisation. In fact the example on http://gregfranko.com/amdclean/ is another one:

// AMD
define('example', [], function() {
  return 'Convert AMD code to standard JavaScript';
});

// Standard JS
var example = function () {
        return 'Convert AMD code to standard JavaScript';
    }();

// but could be
var example = 'Convert AMD code to standard JavaScript';

I was wondering if it's possible to identify these cases (i.e. no dependencies, definition body is a single return statement) and discard the outer IIFE when they're encountered?

[gfranko]

This is definitely possible and shouldn't be too difficult. Basically, if there is only one AST object (e.g function) in the callback function body and no dependencies, then convert the module to the optimized format. I'll try to get this done in the next day or two.

[Rich-Harris]

Brilliant!

[gfranko]

If you can think of any other optimizations, definitely let me know. I think the project is stable enough now that we can now focus on more minor optimizations like this.

[gfranko]

These optimizations have now been incorporated with the 0.7.0 release! Check out the release notes for more details.

Thanks for pointing out these optimizations Rich!

[Rich-Harris]

Excellent! Many thanks. It's been great to watch amdclean get better and better - developing a library as a collection of AMD modules is such a pleasure (testing without building, etc) and it's only practical to do so because of amdclean. Great work.

[gfranko]

You and I like to build libraries in a similar way. Love using AMD for it.

And I appreciate all the kind words, but you should give yourself credit too. AMDClean wouldn't be where it is now without you. Hopefully once I find some free time I can contribute to some of your awesome projects, like Ractive.js

[Rich-Harris]

That'd be great :)