I'm going to redo all the path lookup helpers for 3.x.

I don't particularly like this api. filter? what, paths, assets, it doesn't say.

We could preserve the existing protected API and call it matches_filter? or we could make it more verbose and call it asset_matches_filters? to give a hint of the order of parameters. We need an exposed way to detect if given a set of filters and an asset if sprockets will compile or not compile that asset.

The method doesn't even need to be on environment or index in this case the protected method matches_filter doesn't actually use any methods on Sprockets::Base at all it's purely functional, it only uses elements passed in. If you wanted we could move to a separate class Sprockets::FilterMatcher that could be used to replace the implementation of matches_filter.

We've got options. We need this functionality exposed, I'm very open to how we write the implementation. Let me know which of the above options you like the best, or please suggest something else.

Heres the direction I'm trying to go by exposing more filter as enumerators.

https://github.com/sstephenson/sprockets/blob/master/lib/sprockets/manifest.rb#L109-L151

It should be easier to chain filters on to them. And even better you can use .lazy on Ruby 2.