Uglify modifies code in minified builds
Colin Clark
colinbdclark at gmail.com
Wed Nov 25 17:57:16 UTC 2015
Hi all,
Infusion's build system has always been somewhat idiosyncratic (also ahead of its time, offering developers the ability to freely compose any Infusion module they want into a build), particularly in the way it packages and produces build artifacts in an either/or fashion. I think it needs to be updated.
We should define a set of "base profiles" of Infusion (such as a "framework only" build) and publish them as part of our npm module (using the "prepublish" script hook). Bower is now essentially a dead project and npm has emerged as a viable way of managing client-side dependencies. Both minified and non-minified versions of these builds should be created every time we publish our module.
I don't agree with Michelle that we should disable Uglify's more aggressive compression options unless they produce erroneous code. Obviously, we shouldn't be using Uglify's "unsafe" options, but other optimizations are worth maintaining. While it's undoubtedly a subject of significant debate, I for one still think that minimizing script size is a worthwhile endeavour. If it's easy to do and doesn't affect source code (as opposed to built file) readability, every kilobyte saved is worthwhile.
Minified code is for production, not for debugging during development. If we need to pursue a means for more easily toggling between builds, such as a daily build Node.js app that can serve up either version of our static resources, perhaps it is worth doing so. Or perhaps simply not linking against minified builds on the daily build server, but only on production sites.
Colin
> On Nov 25, 2015, at 12:11 PM, Justin Obara <obara.justin at gmail.com> wrote:
>
> Currently the build process is either minified or source, and it looks like the minified version is the one being used for the build site. It could be an option to change the build process to produce both a minified and source version, and to host both of these on the daily build site.
>
> On November 25, 2015 at 11:33:09 AM, Tirloni, Giovanni (gtirloni at ocadu.ca <mailto:gtirloni at ocadu.ca>) wrote:
>
>> Changing those options seem to be trying to make the uglified code
>> closer to the original version for understandability purposes.
>>
>> I wonder if it's not better to always use the non-uglified code when
>> debugging and only switch focus to the uglified version if the issue
>> can't be reproduced with the original code (which would point to a issue
>> with the uglifier). Are we producing non-uglified code during the build
>> process?
>>
>> Regarding file size, the difference is so small I'm sure it'll be made
>> irrelevant by server-side compression before it arrives at the client. A
>> worse problem is websites that load Infusion multiple times, but I guess
>> that is not in scope here.
>>
>> On 11/25/2015 02:16 PM, Justin Obara wrote:
>> >
>> >
>> > I was code reviewing FLUID-5759
>> > <https://github.com/fluid-project/infusion/pull/655 <https://github.com/fluid-project/infusion/pull/655>> this morning and
>> > was looking into the change that was made. I was trying to step through
>> > the debugger to compare the change against what had previously been in
>> > the codebase. I went to the build site
>> > <http://build.fluidproject.org <http://build.fluidproject.org/>> to step through the tests. First off the
>> > code for Infusion is all minified; however, Safari does a decent job of
>> > separating the code to make it readable. Unfortunately I still could not
>> > find the part of the code I was looking for.
>> >
>> > After more digging I found the line I wanted but noticed that the code
>> > was actually different. I checked through the repository and confirmed
>> > that it was not an issue with the code being out of sync. After running
>> > some local builds it seems that the reason is the compression being done
>> > by Uglify <https://github.com/gruntjs/grunt-contrib-uglify <https://github.com/gruntjs/grunt-contrib-uglify>>. It seems
>> > that be default most of the compression options
>> > <https://github.com/mishoo/UglifyJS2#compressor-options <https://github.com/mishoo/UglifyJS2#compressor-options>> are enabled.
>> >
>> > Example of the change:
>> >
>> > In source:
>> > if (!fluid.isPrimitive(thisCompositeOptions.panels)) {
>> > fluid.each(thisCompositeOptions.panels, function
>> > (subpanelArray, pref) {
>> > subPanelList = subPanelList.concat(subpanelArray);
>> > if (pref !== "always") {
>> > fluid.each(subpanelArray, function (onePanel) {
>> > fluid.set(subPanelRenderOn, onePanel, pref);
>> > });
>> > }
>> > });
>> > } else {
>> > subPanelList = thisCompositeOptions.panels;
>> > }
>> >
>> > In minified:
>> >
>> > fluid.isPrimitive(thisCompositeOptions.panels)?subPanelList=thisCompositeOptions.panels:fluid.each(thisCompositeOptions.panels,function(subpanelArray,pref){subPanelList=subPanelList.concat(subpanelArray),"always"!==pref&&fluid.each(subpanelArray,function(onePanel){fluid.set(subPanelRenderOn,onePanel,pref)})})
>> >
>> >
>> > So far it doesn’t seem to have caused any issues, and they do disable
>> > “unsafe” compression options by default. In theory it should be safe to
>> > leave these on. However, it will mean we have a difference in code
>> > between the minified and source versions. Which, in the least, will make
>> > tracking down code between the two more difficult.
>> >
>> > What are you thoughts, should we keep the full compression or use
>> > smaller subset?
>> >
>> > infusion-all.js with full default compression options is 831KB
>> >
>> > infusion-all.js with the following options disabled, is 844KB
>> >
>> > compress: {
>> > sequences: false,
>> > dead_code: false,
>> > conditionals: false,
>> > booleans: false,
>> > unused: false,
>> > if_return: false,
>> > join_vars: false,
>> > drop_console: false
>> > }
>> >
>> > Thanks
>> > Justin
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca <mailto:fluid-work at lists.idrc.ocad.ca>
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work <http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>_______________________________________________________
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca <mailto:fluid-work at lists.idrc.ocad.ca>
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work <http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20151125/68a124df/attachment.html>
More information about the fluid-work
mailing list