iirc there are some issues with the Apache license in GPLv2. GPLv3
however is fine with the Apache license.
As for dropping JSMin... I never really liked Crockford anyways, nor
JSMin... so I don't really have any problem. I also don't like the idea
of maintaining what's essentially a local fork from the upstream, so if
this is a performance improvement and eliminates the need to fork
something to get it to do what we want... perfect.
Personally I always had a preference towards YUI's minifier. I haven't
quite jumped onto closure just yet... in the early days I wasn't sure
about trusting it to not introduce edge cases into code (since it
basically does some rewriting of code above what other minifiers do and
I wasn't sure about it's implementation.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
On 11-01-20 06:57 PM, Michael Dale wrote:
As mentioned in the bug, it would be nice to have
configurable support
for the closure-compiler as well ;) ( I assume Apache licence is
compatible? )
Has anyone done any tests to see if there are any compatibility issues
with SIMPLE_OPTIMIZATIONS with a google closure minification hook?
--michael
On 01/20/2011 04:13 PM, Trevor Parscal wrote:
> For those of you who didn't see bug 26791, our use of JSMin has been
> found to conflict with our GPL license. After assessing other options (
>
https://bugzilla.wikimedia.org/show_bug.cgi?id=26791#c8 ) Roan and I
> decided to try and use the minification from JavaScriptPacker, but not
> its overly clever but generally useless packing techniques. The result
> is a minifier that outperforms our current minifier in both how quickly
> it can minify data and how small the minified output is.
> JavaScriptDistiller, as I sort of randomly named it, minifies JavaScript
> code at about 2x the speed of Tim's optimized version of JSMin, and 4x
> the speed of the next fastest PHP port of JSMin (which is generally
> considered the standard distribution).
>
> Similar to Tim's modified version of JSMin, we chose to retain vertical
> whitespace by default. However we chose not to retain multiple
> consecutive empty new lines, which are primarily seen where a large
> comment block has been removed. We feel there is merit to the argument
> that appx. 1% bloat is a reasonable price to pay for making it easier to
> read production code, since leaving each statement on a line by itself
> improves readability and users will be more likely to be able to report
> problems that are actionable. We do not however find the preservation of
> line numbers of any value, since in production mode most requests are
> for many modules which are concatenated, making line numbers for most of
> the code useless anyways.
>
> This is a breakdown based on "ext.vector.simpleSearch"
>
> * 3217 bytes (1300 compressed)
> * 2178 bytes (944) after running it through the version of JSMin that
> was in our repository. Tim modified JSMin to be faster and preserve line
> numbers by leaving behind all vertical whitespace.
> * 2160 bytes (938 compressed) after running it through
> JavaScriptDistiller, which applies aggressive horizontal minification
> plus collapsing multiple consecutive new lines into a single new line.
> * 2077 bytes (923 compressed) after running it through
> JavaScriptDistiller with the vertical space option set to true, which
> applies aggressive horizontal minification as well as some basic
> vertical minification. This option is activated through
> $wgResourceLoaderMinifyJSVerticalSpace, which is false by default.
>
> The code was committed in r80656.
>
> - Trevor (and Roan)
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]