Feature request from keithbentrup, posted on GitHub Jan 19, 2016
Steps to reproduce 1) Install the reference store with a sample data 2) Configure js minification and deploy static assets 3) Visit a product page Expected result: Product page loads with product image and no js error in the js console Actual result: Product pages with no product image and a js error
Comment from guz-anton, posted on GitHub Jan 25, 2016
Keith, thanks for investigation. Yes, we also found that JShrink minifier corrupt
fotorama.js. So as quick solution we place
fotorama.min.js nearby main file.
Your proposal about yuicompressor is good solution. But it is an Java application. Magento cann't rely on +1 technology in critical application flows. Otherwise we could use NodeJs + UglifyJs as engine for minifying.
So at this moment we are not going to use yuicompressor or Google Closure Compiler as main engine for processing assets.
Comment from keithbentrup, posted on GitHub Jan 25, 2016
@guz-anton Ok, there is a secondary issue here though. The underlying filesystem affects which file is returned first for minification. On linux, the code reads fotorama.min.js first, copies the file to pub/static/, and continues without issue. In my tests on OSX, the code reads fotorama.js first, minifies (and BREAKS it!), copies the file to pub/static/, and continues to fotorama.min.js from the Magento dir. However, now since fotorama.min.js exists in the destination folder pub/static, it will not overwrite the broken file with the existing fotorama.min.js from the source folder. (Should we record this as a separate bug?)
Either way, broken minification definitely needs to be addressed. I don't think using JShrink (something known to break valid js) is an acceptable solution, and I would argue that Magento is already clearly relying on "+1" technology for many other scenarios. It doesn't have it's own built in app server or it's own built in database server.
Comment from southerncomputer, posted on GitHub Jun 08, 2016
https://github.com/magento/magento2/issues/4506 this is a duplicate ?
Comment from southerncomputer, posted on GitHub Jul 15, 2016
@keithbentrup are you sure this in not caching at the apache/nginx - or php realpath or php opcache accelerator that is racing it's own caching (file_exists) against dynamic creation of files?
I've found this to be the case with php_opcache - so i disabled revalidation and manually do service php-fpm restart after any code/config/cache change (plus service nginx restart plus service varnish restart) - plus i disable CLI opcache mode since that can't be easily flushed!