would love a config flag to never pipeline external (ex: cdn) assets about assets HOT 5 CLOSED

@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.

from assets.

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

from assets.

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

from assets.

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

from assets.

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

from assets.