JavaScript port of Sprockets (v2.10.0). It features same declarative dependency
management (with exactly same language) for CSS and JavaScript and preprocessor
pipeline. Mincer allows you to write assets in the languages like: CoffeeScript,
LESS, Stylus and others. Moreover mincer has advanced built-in features, not
available in sprockets:

You'll need an instance of the Mincer.Environment class to
access and serve assets from your application.

The Environment has methods for retrieving and serving assets, manipulating
the load path, and registering processors. It is also used by Mincer.Server
which can be mounted directly as request event handler of http.Server or
as connect middleware.

The load paths is an ordered list of directories that Mincer uses to search
for assets.

In the simplest case, a Mincers environment's load path will consist
of a single directory containing your application's asset source
files. When mounted, server will serve assets from this directory as if
they were static files in your public root.

The power of the load path is that it lets you organize your source
files into multiple directories -- even directories that live outside
your application -- and combine those directories into a single
virtual filesystem. That means you can easily bundle JavaScript, CSS
and images into a library and import them into your application.

When you mount an environment, all of its assets are accessible as
logical paths underneath the mount point. For example, if you mount
your environment at /assets and request the URL /assets/application.js,
Mincer will search your load path for the file named application.js
and serve it.

Asset source files can be written in another language, like Stylus or
CoffeeScript, and automatically compiled to CSS or JavaScript by
Mincer. Compilers for these languages are called engines.

Engines are specified by additional extensions on the asset source
filename. For example, a CSS file written in Stylus might have the name
layout.css.styl, while a JavaScript file written in CoffeeScript
might have the name dialog.js.coffee.

Mincer supports JavaScript templates for client-side rendering of strings or
markup. JavaScript templates have the special format extension .jst and are
compiled to JavaScript functions.

When loaded, a JavaScript template function can be accessed by its logical path
as a property on the global JST object. Invoke a template function to render
the template as a string. The resulting string can then be inserted into the DOM.

If jade Node module is available to your application, you can use Jade
templates in Mincer. Jade templates have the extension .jst.jade. To use
compiled templates you will need to require Jade runtime before
calling renderer functions.

Mincer provides an EJS engine for preprocessing assets using
embedded JavaScript code. Append .ejs to a CSS or JavaScript asset's
filename to enable the EJS engine.

You will need ejs Node module available to your application.

Note: Mincer processes multiple engine extensions in order from
right to left, so you can use multiple engines with a single
asset. For example, to have a CoffeeScript asset that is first
preprocessed with EJS, use the extension .js.coffee.ejs.

JavaScript code embedded in an asset is evaluated in the context of a
Mincer.Context instance for the given asset. Common uses for EJS include:

embedding another asset as a Base64-encoded data: URI with the
asset_data_uri helper

inserting the URL to another asset, such as with the asset_path
helper (you must register your own helper for this purpose, but
it's dead simple).

embedding other application resources, such as a localized string
database, in a JavaScript asset via JSON

This feature is designed as simple alternative to EJS, that does not requires
additional extention and does not break language syntax. When enabled, any
'$$ expression $$' or "$$ expression $$" pattern will be replaced with
evaluated expression value. In expression you can write JS code and use
registered helpers. Macros are off by default. You should enable those for
particular extentions:

You can create asset bundles -- ordered concatenations of asset
source files -- by specifying dependencies in a special comment syntax
at the top of each source file.

Mincer reads these comments, called directives, and processes
them to recursively build a dependency graph. When you request an
asset with dependencies, the dependencies will be included in order at
the top of the file.

The first word immediately following = specifies the directive
name. Any words following the directive name are treated as
arguments. Arguments may be placed in single or double quotes if they
contain spaces, similar to commands in the Unix shell.

Note: Non-directive comment lines will be preserved in the final
asset, but directive comments are stripped after
processing. Mincer will not look for directives in comment blocks
that occur after the first line of code.

stubpath allows dependency to be excluded from the asset bundle.
The path must be a valid asset and may or may not already be part
of the bundle. Once stubbed, it is blacklisted and can't be brought
back by any other require.

Great thanks to Sam Stephenson and Joshua Peek for the Sprockets,
the most awesome and powerfull web assets processor I ever used, and which
became a great source of inspiration (and model of almost all logic behind
Mincer). Special thanks to Joshua for his assistance in hacking into Sprockets
sources.