[PROPOSAL] Build tool to optimise Imager library (so it includes only code actually used)

[Integralist]

Looking over the proposals that @oncletom has written up, it seems like it would be a good idea to have some form of Grunt task that the user could use to optimise the API of Imager.

By this I mean, if we look at #25 (triggering events manually), I suggested making sure the default behaviour was the resize event and the user could override that behaviour. So if the user decided to do just that, the Imager library would still have a chunk of code that would no longer be needed in production. It would be good if they could run a grunt task which they could specify what API's they have used (or which they have overridden) and then Grunt would clean-up the Imager library code so it only included code actually used.

[thom4parisot]

Regarding #25 and some other, that's true it can become counter productive only for the sake of the filesize and the context. I like your idea of having some features shipped in the core experience and enabling them to build their own flavour by removing/adding other features at build time.

Additionally to a grunt task, it would make sense in combination with an updated @kaelig's Imager.js customiser.

[Integralist]

@oncletom sounds good to me

[addyosmani]

Although a more complex example, you might find it useful looking at how grunt-modernizr solved this problem for their task for building leaner versions of Modernizr https://github.com/Modernizr/grunt-modernizr/tree/master/lib.

Alternatively, ensuring that all non-core features are shipped as plugins makes that task of dropping unused features at build-time a great deal more easy. This is the approach taken by the jQuery project and others who found actual build-time parsing to be a less ideal option.

[thom4parisot]

What do you think of browserify? If we use it to generate UMD module, we can use require() to load internal modules and create various bundle files. And it let people building their own flavour of Imager.

[addyosmani]

For folks who like to keep everything in the same package manager, it's certainly a means to an end :)

On UMD: I think that as long as the final version built for the user doesn't suffer from too much wrapper overhead, that option is appealing and as you mention, would let us create various bundles.

[Integralist]

Agreed with @addyosmani on trying to prevent wrapper'itus if possible :-)