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 w
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, rep
When I use libraries like jQuery (not sure about frameworks) I expect
a choice of ways too include the JS
* Hosted on a CDN non minified (probably gzipped)
* Hosted on a CDN minified
* Download a tarball with minified and non minifed versions
* Download through a package manager
* Build custom ver
Antranig,
> On Nov 25, 2015, at 2:24 PM, Antranig Basman
> 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 stru
This remark:
> "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) rea
Hi Antranig,
> On Nov 25, 2015, at 1:48 PM, Antranig Basman
> wrote:
>
> If we don't have time for this, the 13K savings through disabling the extra
> optimisations seem neither here nor there - and having code without any
> whitespace appear in the debugger seems equivalently obstructive to
I have read ahead in this thread (up to the current time) but thought
I'd reply to the original message since it contains the relevant
transcripts.
I'm wondering what the source of surprise is, "that the code was
actually different" - isn't this exactly the behaviour we expect from a
compress
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 nee
Interesting thread. I've not used uglify but assumed from the name
that it's purpose was to mangle code - but I see that is just one
option.
I'm probably teaching granny to suck eggs but in compiled source
development like C you almost always have 2 separate builds.
* debug: not code mangling opt
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 Novem
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 th
Thanks for looking into this Justin.
I think we should disable the compression options. Leaving the compression
options on means that the minified code base is considerably different from the
unminified code base. I don’t think the small change in file size is worth the
increased complexity in
I was code reviewing FLUID-5759 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 to
step through the tests. First off the code for Infusion is a
13 matches
Mail list logo
