Surf use-aggregate-dependencies and yuicompressor

[loftux]

I want to understand when yuicompressor is used in combination with the upcoming Surf feature use-aggregate-dependencies.

My concern here is that yuicompressor actually have some bugs that cause compressed files not to be usable. If you have complete control over the code you can of course make sure you avid those bugs, but if you use 3rd part javascript libraries this is not always something you can control.

One example is the pdf.js based viewer currently beeing developed in Share Extras project. The pdf.js library cannot be compressed with yuicompressor due to this bug http://yuilibrary.com/projects/yuicompressor/ticket/2528049. So we use jsmin for that library specifically.

But you still may want to use 'use-aggregate-dependencies' for all other code in Share, not to turn that off because of use of an addon.
- Will the yuicompressor only be used if Surf cannot find a minified version of the script or will yuicompressor be run on the concatenated script always?
- Can you avoid this instead by not using the "group" directive, ie the non yui compressable script cannot be part of an aggregation, but that ok since it is an exception an you can take advantage of the aggregation for all other scripts.

[loftux]

OK, just tested this with code from HEAD and the pdf.js viewer from Share-extras.
Use of aggregate-dependencies breaks the viewer as it minifies with yuicompressor, and this creates broken code in this particular case.

As I think the aggregation is a really usefull feature to minimize the number of requests to the server I hope that there could be a way to tell not to include selected scripts. Or use the already minified version if present.

[ddraper]

Hi,

First off, apologies for missing both posts on this topic and thanks for the Tweet to bring it to my attention…

It's important to remember that we're not intending to run Share in the aggregated-dependency mode by default but that it's something there to be used if required. We're still not completely through the process of updating all the Share WebScripts to support this feature (but we're now very close!).

It is possible to to have aggregation without compression by running Share in debug mode however this will result in all uncompressed files being loaded by default which I suspect is not what you want either. Your best option for specific exclusions would be override the default Spring configuration for the "dependency.aggregator" bean to provide your own implementation and override the "compressJavaScript" method to handle exclusions (which you could also define in the Spring config).

This actually sounds like a valuable update to core Surf but I'm not sure when I'd have the time in my current schedule to make this update.

Regards,
Dave

[loftux]

I added an enhancement request for this. When you or someone else at Alfresco finds time…
https://issues.alfresco.com/jira/browse/ALF-15473
Without having tested, I cannot see why aggregation (without being yuicompressed, instead use already compressed files) should not be safe. Cannot be that much different than loading them one after the other. If it gives enough in terms of performance so the change is worth it I have no idea.

For the above use case in Share-extras Media viewer we just need to the documentation when we release for 4.2 that aggregation breaks functionality and should not be turned on for now.

[ddraper]

Also… did you know that you can change the YUI compressor settings used by the dependency aggregator via the "dependency.aggregator" bean properties? Would disabling the opimizations and/or preserving semi-colons make a difference to the files that is getting corrupted?

[loftux]

I've tried in the build for Media Viewers all sorts of settings for the yuicompressor, and in this case it is truly a bug, it hits the bug linked in the first post. Since the pdf.js files are external library files we have no control of the coding style in that project https://github.com/mozilla/pdf.js. Adding to this bug, pdf.js developers insist on using reserved keywords… https://github.com/mozilla/pdf.js/issues/710

But an exclusion pattern as per your comment in my enhancement request would work. If you by that mean for production mode read the compressed file, if found use that file in aggregation, if exclusion pattern is matched, do not compress. Could possibly be the same pattern already defined by bean dependency.handler and productionSuffices. In a way this is what is already done when aggregation is not turned on.

[ddraper]

It's not quite the same thing because the dependency handler makes no assumption on the file contents. When a request is made it is just for a file (e.g. "my-file.js") and when in production mode the handler (when in production mode) will first look for "my-file-min.js", then "my-file-minified.js" and finally just "my-file.js"… it's possible that both "my-file-min.js" (a build compressed file) will be matched but that then uncompressed "my-file.js" will also be available (for debug purposes).

This is why we can't use the same list for excluding files from runtime compression during aggregation - we may want to exclude "-min.js" and "-minified.js" files from passing through compression again - but we don't want to exclude all other files. This is why it would be better to have a separate list that is part of the aggregation handler configuration.

Regards,
Dave