This project is read-only.
1

Closed

CompressionType = None?

description

Add an option to combine the incoming files only - ie, no compression or other optimisations will be applied, as per: http://yuicompressor.codeplex.com/discussions/286444
Closed Jan 28, 2012 at 1:31 PM by freeranger

comments

freeranger wrote Jan 27, 2012 at 9:40 PM

Ok, so we have two choices here:
  1. We have an existing CssCompressionType, so we can add "None" as an option to that, and introduce a new "JavaScriptCompressionType" with values of "None" and "StockYuiCompressor"
  2. We refacor to have a single ComressionType:
    public enum CompressionType
    {
    None,
    StockYuiCompressor,
    MichaelAshRegexEnhancements,
    Hybrid
    }
which, for Css, behaves exactly as it currently does (except, of course, for the new "None" option), and for Javascript, basically is either "None" for no compression or any other of these enum values to mean the standard YUI javascript compression we have.

There are advantages and disadvantages to each:
  1. has the advantage of continuing the separation of css and javascript, but then we are adding yet another parameter to the MSBuild Task
  2. has the advantage of having a single unified CompressionType, so reducing complexity/user confusion, but then a) it breaks the existing system and b) most of the values have no real meaning when compressing javascript files (as in they perform the same function).
Personally I don't tend to compress css and js in the same call, so I would prefer a single CompressionType and the fact that most values make no difference for javascript is neither here nor there (I tend to use the stock compression so could do without the rest), but I am conscious that "CssCompressionType" is already "out there", and that having redundant values (for js compression) is not really ideal...

Thoughts anyone?

wrote Jan 27, 2012 at 10:20 PM

freeranger wrote Jan 28, 2012 at 8:18 AM

My own thought now, in the cold light of day is that option 1 is the way forward, to maintain comparability for dependent users. Maybe some major breaking revision in the future will change this, but it's not reason enough to break things right now. As you were people ;)

wrote Jan 28, 2012 at 1:31 PM

Resolved with changeset 74419.

wrote Feb 22, 2013 at 12:55 AM

wrote May 16, 2013 at 12:20 PM

wrote Dec 8, 2017 at 5:08 PM