[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

> 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 Mas

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

Reply to: