[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Minified files and source code requirement



Pau Garcia i Quiles, 2011-10-27 11:22:08 +0200 :

> On Thu, Oct 27, 2011 at 10:47 AM, Roland Mas <lolando@debian.org> wrote:
>>> Requiring the non-minified file to be provided in the same source
>>> package is not a very productive use of our time.
>>
>>  Right.  In the same way that providing the source for our binaries
>> isn't very productive, I guess, because who's going to use it when they
>> have the pre-built binaries?  I know this is an exaggeration, but
>> there's no substantial difference between the two cases.
>
> But we provide *source packages*. We do not provide the source in the
> *binary* package.

  Quite true.

> That's what Raphael is talking about: having the minified and the
> original (non-minified) JavaScript in the *same* package (which would
> be the binary package, and also the source package).

  I don't think anyone is actually arguing in favour of shipping the
original JS in the binary packages.  The point being argued is whether
shipping *only* the minified JS in the source package is correct or
not.

> I said this in the original thread and I'll repeat it here: if we have
> the non-minified JavaScript, then I see no problem in providing only
> the minified version in the binary package.

  Agreed, if the minified version is actually generated during the
package build.  If it's not, then we get back to the initial problem.

> To me, these are equivalents:
>
> Minified Javascript                         == ELF binaries
>
> Original (non-minified) Javascript  == C++ source code
>
>
> And that's not entirely true, btw, because it depends on what minifier
> has been applied. IIRC JSMIN and Packer do not modify the source
> (therefore you can always go back to the original JavaScript just by
> re-applying whitespace, indendation, etc), while yui-compressor and
> Google's do modify the source to remove dead branches, optimize, etc

  The ELF binaries also depend on compiler versions, options and phase
of the moon, so the analogy isn't that wrong.

> My proposal:
>
> 1. Have multiple versions of JavaScript libraries, very much like we
> have multiple versions of binary libraries with soversions, different
> package names (libfoo1, libfoo2, etc). We would have libjs-jquery1.4,
> libjs-jquery1.6, etc
>
> 2. If upstream only provides the original (non-minified) JavaScript,
> then we do not have a problem. This never happens, AFAIK.

  Not quite true; FusionForge upstream in particular ships some complete
versions of some jQuery plugins (FusionForge as a Debian package takes
care to use the system libraries).  But that's a minor point :-)

> 3. If upstream only provides the minified JavaScript, add the package
> for the non-minified JavaScript as a build dependency and re-minify
> it. This is what I do in witty, for instance.
>
> 4. If upstream provides the original (non-minified) JavaScript *and*
> the minified JavaScript, ignore both of them and do same as 3

  This all boils down to "treat Javascript libraries exactly the same as
libraries in other languages", and I'm all in favour of that.

Roland.
-- 
Roland Mas

The best definition of an immortal is someone who hasn't died yet.
  -- in Ye Gods! (Tom Holt)


Reply to: