This wouldn’t be an issue if npm made it possible to visualize which packages are most actively being developed, maintained, and widely used. When looking for an asset manager, I found out there were at least five different asset managers I just had to try. But their interfaces felt clunky enough I ended up deciding to contribute to the mess with yet another asset manager package.

Features

I wanted an asset manager that was:

• Easy to configure, I didn’t want to spend hours figuring out what the package source was doing, or supposed to be doing
• I wanted to be able to create different profiles, yet manage everything the exact same way
• I wanted it to support pre-processing, such as compiling SASS or CoffeeScript
• Extensible, so that if it didn’t support something out of the box, I could extend it intuitively to get the behavior I expected
• Bundling and minification was also a must, but I wanted to be able to control this.

And besides the above, I wanted the package to also deal with rendering the <script> and <link> tags. And I wanted it to do this in the same order I passed to the asset manager configuration, since order matters.

Introducing node-assetify

I attempted to cover most of assetify’s functionality in its documentation on GitHub.

I think I did a good job of keeping the interface assetify exposes clean and simple. It supports a similar API on the server-side, through the require('assetify') module as it does on view contexts, through res.locals.assetify.

I built it in such a way that allows you to switch between development and production modes just by turning a boolean, something I couldn’t accomplish with the packages I’ve tried out.

My most recent addition to it (currently version 0.0.8) was dynamic asset management, which, even though I didn’t need for Pony Foo, I felt this was a feature that couldn’t be missing in assetify.

A useful pattern in web architecture is to decompose views into smaller chunks, or partial views. One of the drawbacks of such modularization, is handling script blocks. If you’re a purist, you’ll irrevocably want your script blocks grouped together at the bottom of the page. But you’ll also want to declare them in the same partial view where you are going to be needing them.

Dynamic assets to the rescue

With assetify, you can use res.locals.assetify.js.add, or just assetify.js.add in view contexts, to keep your partials tidy and your scripts grouped. This method is just a glorified way of pushing the source code passed to the add function into an array in the request object. Then, when the time comes to .emit() your script blocks, dynamic asset blocks will be emitted as well, right after compiled static assets, where they belong.