On Mon, May 29, 2017 at 18:04:19 +0200, Ludovic Courtès wrote: > Jelle Licht skribis: >> Another issue with minifiers in general is that is Very Hard to write a >> proper minifier. If we choose to not use the minifier as expected by the >> package author, we will at some point run into issues that will be very >> hard to report and get fixed upstream, as it will only be us experiencing >> these issues due to our ... unique .. build procedure. > > Sure. My suggestion would be to use an existing, established minifier, > only one that is relatively simple to package. It could be one written > in a language other than JS (Ricardo mentioned ‘cl-uglify-js’ on IRC), > or it could be a simplistic minifier written in JS but with very few or > not dependencies, if that exists. Further, minifiers have various options and some methods are more aggressive than others. Last I checked a couple years ago, for example, Closure Compiler broke GNU ease.js on its more aggressive setting. The break was obvious from running my test suite, but some breaks were subtle and would have caused nightmares in production. Perhaps things have since improved. My point is, though, that Jelle's concerns are shared. Closure Compiler is written by Google, and they tend to know what they're doing in this area. ;) I'm not saying I'm opposed; it sounds fine to me. Just be careful! -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com