Uglify modifies code in minified builds

[Colin Clark]

That seems like a pretty sensible approach to me, too. What do others think?

Michelle mentioned that she might has some spare cycles as part of her UIO improvement work to add source maps support to our build. It sounds like it's just a matter of familiarizing ourselves with it and considering what the best way is to distribute source maps with a build (if at all).

Colin

> On Nov 25, 2015, at 4:22 PM, Antranig Basman <antranig.basman at colorado.edu> wrote:
> 
> Thanks for the response, Colin - sorry for misreading your previous message. The difference in size between the minified and concatted builds is very significant and I agree that we shouldn't go forward without our existing minified build as part of our set of standard builds.
> 
> This, to me, represents a substantial support risk, and I'd like to see us try to bridge the gap between your points 2. and 3. with some kind of cheaper, transitional strategy. This might be as simple as just tweaking our uglify options to include "sourceMap: true" -
> 
> https://github.com/gruntjs/grunt-contrib-uglify#sourcemap
> 
> Even if we don't have any formal process for distributing the map, we would at least know that it had once existed and could be regenerated, and that, presumably, the special comment indicating that a source map exists will be added end of the built file:
> 
> http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
> 
> That is - should we unexpectedly find ourselves in the position of having to debug a production usage of Infusion, all we might need to do is drop an extra file (the map) into the production server. The mere presence of the maps might also promote some opportunistic exploration of using them in the intervening time.
> 
> Cheers,
> Antranig
> 
> On 25/11/2015 20:34, Colin Clark wrote:
>> Antranig,
>> 
>>> On Nov 25, 2015, at 2:24 PM, Antranig Basman <antranig.basman at colorado.edu> wrote:
>>> 
>>>> "Minified builds aren't intended for development. They're designed
>>>> for production, and we shouldn't be either surprised or terribly
>>>> concerned by the idea that somehow magically the code changed in
>>>> layout or structure as a result of minification. That's what it's for!"
>>> 
>>> i) reacts to a partial reading of my posting - the first paragraph of which contains (part of) exactly the same point you are making here - that we should not be surprised that the layout of code has changed due to minification
>> 
>> I did indeed read that part of your post, and was intending to reinforce it with my agreement. I apologize if that agreement wasn't clear; I don't think our positions are terribly far apart.
>> 
>>> ii) cuts against one of our core principles - that we should treat different parts of our authorial lifecycle - development, maintenance, production, or any other deployment context - as part of the same process. We should expect to be able to debug or work with any kind of deployment of Infusion on equal terms. Infusion is about equality of authorial access.
>> 
>> I understand this principle and agree with it. My concern is largely specific: dispensing with minification for Infusion right now will put a particular category of users in an awkward position. We have users of UI Options, for example, who expect to be able to take a bundle of JavaScript and a small number of HTML templates and embed them directly in their websites. No build process, no in-depth knowledge of JavaScript production packaging techniques, and not even an understanding of what all the pieces and parts are that compose UI Options.
>> 
>> The unminified UI Options build is over 50% larger than the minified version. So we're not talking about 13K here or there, but quite a lot more. I think it's important to give users a minimal, out-of-the-box distribution of UI Options that they don't have to process or manipulate in any way. We're not quite there (in that users still have to follow a tutorial on how to make a custom build), but we shouldn't go backwards in this regard. I worry that if we dispense with minification entirely, it will be a step back. Perhaps I was misunderstanding your argument.
>> 
>> What I'm suggesting, and I apologize if it wasn't clear in my earlier responses, is this:
>> 
>> 1. We don't try to debug minified builds. If we expect to use our daily build server as a place to do debugging and troubleshooting (and I think we should), it should always employ unminified builds.
>> 
>> 2. We retain uglification with its default options, making it available for users (such as "plug and play" UI Options users) on their production sites (by creating a --source false build).
>> 
>> 3. When we find the cycles, to a) add source maps support for our minified builds, and b) update our build system to produce both minified and unminified versions of "standard profiles" of Infusion such as framework-only, UIO-only, etc. and publish them via an npm prepublish script.
>> 
>> In the longer term, after #3, we should consider a much more in-depth process that will enable applications to be seamlessly moved from more to less "compiled" form and back again for authorial and debugging purposes throughout the application lifecycle.
>> 
>> What are your thoughts on this?
>> 
>> Colin
>> 
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work