This increases file size even further, so eventually we may want to add
ranges. That said, it's not that significant, and helps to make the life of
the project prominant.
As suggested by RMS in The JavaScript Trap:
<https://gnu.org/philosophy/javascript-trap.html>
This does increase the size of the minified file a bit---the header is now
about 1kB of uncompressed text (which will hopefully comprses nicely with
the rest of the minified file). That said, ease.js will be continuing to
grow in size, bandwidth is becoming less and less important, and the license
is very important, especially in our goal to spread the philosophy of
software freedom.
On Sun, Dec 22, 2013 at 03:31:08AM -0500, Richard Stallman wrote:
> I hereby dub ease.js a GNU package, and you its maintainer.
>
> Please don't forget to mention prominently in the README file and
> other suitable documentation places that it is a GNU program.
Thanks again to Brandon Inverson for providing this patch. All changes are his
except for the comment in configure.ac and the version.js.tpl move/changes.
Copyright-paperwork-exempt: Yes
This greatly simplfies rebasing and other operations while working in a branch;
signing each and every commit that is not in master can be overkill (even if it
does give peace of mind).
This project was originally LGPLv+-licensed to encourage its use in a community
that is largely copyleft-phobic. After further reflection, that was a mistake,
as adoption is not the important factor here---software freedom is.
When submitting ease.js to the GNU project, it was asked if I would be willing
to relicense it under the GPLv3+; I agreed happily, because there is no reason
why we should provide proprietary software any sort of edge. Indeed, proprietary
JavaScript is a huge problem since it is automatically downloaded on the user's
PC generally without them even knowing, and is a current focus for the FSF. As
such, to remain firm in our stance against proprietary JavaScript, relicensing
made the most sense for GNU.
This is likely to upset current users of ease.js. I am not sure of their
number---I have only seen download counts periodically on npmjs.org---but I know
there are at least a small number. These users are free to continue using the
previous LGPL'd releases, but with the understanding that there will be no
further maintenance (not even bug fixes). If possible, users should use the
GPL-licensed versions and release their software as free software.
Here comes GNU ease.js.
This tool can help to ensure that commits have not been falsely authored. For
example, if you receive an ease.js repository from a friend, there is no way to
verify that a commit from "Mike Gerwitz" is actually a commit from myself unless
it has been signed using my private key. This additional check will help to
ensure the integrity of the repository.
Please note that automated systems should *not* invoke this utility directly
from this repository, unless it is invoked using a previously trusted commit.
Otherwise, an attacker need only alter the script to competely evade the check.
After dealing with autoconf, I may decide not to implement it. The build process
is fairly simple as it is and I do not want to over-complicate it. verset solves
one of the issues that autconf would have aided in addressing - setting a
version number.
Getting ready for release means that we need to rest assured that everything is
operating as it should. Tests do an excellent job at aiding in this, but they
cannot cover everything. For example, a simple missing comma in a variable
declaration list could have terrible, global consequences.
This is nothing against uglify. Rather, here's the story on this:
Commit e4cd1e fixed an error that was causing minified files to break in IE.
This was due to how IE interprets things, not how UglifyJS was minifying them.
Indeed, Closure Compiler had the exact same problem.
The decision to move to Closure Compiler was due to a variety of factors, which
came down to primarily feature set and tests. Closure Compiler is well tested
and maintained. It also includes a number of additional, beneficial features.
UglifyJS is an excellent project and I would recommend it to anyone, but it is
not tested (no unit tests; it's tested by ensuring common libraries like jQuery
run after minification). It is, however, significantly faster.
It's likely that, in the future, once I add autoconf for the build process to
configure certain settings, that I will add UglifyJS as an option. I'm sure many
people would prefer that, especially those who dislike Java and do not wish to
have it installed. Hopefully those that do decide to install Java will go with
openjdk, not Oracle's proprietary implementation.
Mike Gerwitz