Minify 2.1.4 is approaching release and will have several long-awaited features and hopefully easier configuration.

Looking towards version 2.2/3(?), I recently committed the beginnings of a complete refactoring of the Minify API. The goal is to have a more flexible and extensible design that can include plugins like LESS and maybe handle @imports on the server-side—I’m still mulling over how radically a plugin should be able to alter the overall processing of the request. A key to doing this is splitting plugins into at least two stages and allowing the first to influence the cache id, and possibly add more sources/processors. By asserting that the request’s cache id is stable after the first stage, you can serve requests from the cache most of the time without running the second stage (JSMin, calls to Closure Compiler API, etc.).

Another goal was to eliminate static/global state from all components and have each component independently testable, meaning refactoring out access to global state like request/$_SERVER vars, file access from controllers, etc. A bunch of new classes and interfaces (read: files) could mean a performance hit, but we will also add an internal URL cache so that most requests will not load the system at all. At most once every N seconds the full stack will be loaded in order to make sure the cache is up-to-date with file mtimes, etc., but most requests will hit a very minimal front controller that simply includes a pre-generated PHP script (sending the necessary headers and output) depending on query string and Accept-Encoding. In theory this should be absurdly fast (for PHP output anyway), but of course sticking a reverse proxy in front is always a better idea if you can.

There’s a lot of work to be done. I thought of the URL cache a little late so some of my earlier design decisions were based on performance, and they need to be revisited.