would love a config flag to never pipeline external (ex: cdn) assets

[C-Bass]

First of all thanks for your work on this excellent library. I've been using it for a few months and have been enjoying it.

As for my request, I know this can be done by having two instances of the class, which I already intend to do anyway. I would really need 3 instances in that case.. which I'm sure is doable. But I don't think this is an elegant solution.

I also think it's redundant to take an external asset such as a library hosted for free on a free CDN and download it and then minify it only to save a few requests. The requests saved are cancelled out in my opinion by the fact that you are now hosting the file which was otherwise free bandwidth.

As such I think it's pretty common for people to choose not to concat/minify externally hosted files.

So it would be great to either have a true/false config option for never pipelining external assets (if its starts with // or http. OR even better would be an array of whitelisted/blacklisted urls to never pipeline. I know you've mentioned in another issue that 'exceptions' don't fit in the way the library works currently.. but I would like to see if maybe you can think of a way to make it work now. If not oh well.. I just think exceptions and a way to pipeline this collection but now this one would really improve the usefulness of this library.

Thanks for reading

[Javi]

@vesper8 , thanks for using the library.

There is already the config option no_minification_regex which accepts a regex pattern. All assets matching that regex will not be minified by the pipeline. The assets will still be downloaded though.

The default value is /.[-.]min\.(css|js)$/i. Just modify it to include the CDN hosts.

[C-Bass]

hrm.. but I said nothing about not minifying externally hosted files. I would like them to be ignored by the pipeline altogether. That means no concat either. I just want them to be left alone so they are outputted as external assets and left out of the pipelining. Unless your no_minification_regex does this then I don't see why you closed the issue because minification doesn't even relate to the issue I raised.

I know I used the term contact/minify but if you read what I wrote then you know I meant that I wanted external assets to remain external.

Thanks

[Javi]

So basically you want an option for bypassing the pipeline for only some specific assets even if the pipeline is enabled. First, that breaks the very concept of pipeline and second the only solution I can think of for adding such option without having to rewrite almost all the library involves breaking another of its keys principles: FIFO (First in, first out). For implementing it respecting FIFO I'm afraid I will require using several queues each one with its own settings and flow which involves refactoring the whole library since it will affect the pipeline, rendering, adding/deleting and config methods. A big refactor also involves rewriting the tests and the documentation.

Also, it will arguably break another key concept: An ultra easy to use assets library. The moment you have to explain that the pipeline is not a pipeline or that there are different assets flows, in my opinion it starts to have a smell of not simple at all.

It should be easy to foresee that implementing something that breaks several key concepts will involve a lot of work. I also think the reason given for the need of such option (save some of your bandwidth at the expense of other's bandwidth) is not enough to justify a big refactor of the library. Since the request breaks key concepts of the library and cannot be easily implemented I don't thing it will happen but of course if someone finds a clever way to add it without a mayor refactor I'm open to accept it via Pull Request (please don't forget to update the tests and the docs too).

The easy solution is to use multiple instances. Think it well, what is better? one complex library with multiple queues/settings/flows or one simple library with single queue/settings/flow used several times?.

If you use Laravel I have explain several times how to achieve multiple instances of the library with a few lines of code. For instance, assuming you stored two instances 'stolz.assets.pipeline' and 'stolz.assets.nopipeline' in the IoC, you can do things like:

app('stolz.assets.pipeline')->add('foo.css')->css();
app('stolz.assets.nopipeline')->add('bar.js')->js();

You can make it more elegant using a helper function:

function assets($flow) {
    return app("stolz.assets.$flow");
}

Which translates the code to:

assets('pipeline')->add('foo.css')->css();
assets('nopipeline')->add('bar.js')->js();

I could easily implement this (and with this I mean multiple instances, no multiple queues in one single instance) in the service provider by only changing a few lines of code and making the config file to have options grouped in nested sections. But the problem is this is a framework agnostic library so instead of also breaking that key principle I explain how to implement it by yourself

[Javi]

I've just added the multitenancy feature. It implements the solution I mentioned that was easy but breaks the FIFO feature.

[C-Bass]

Thank you very much for implementing this new feature :) Having it built-in is very useful!