Uglify modifies code in minified builds

[Colin Clark]

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