minifyjs / minifyjs

JavaScript minifier written in PHP, seeking to provide ultimate compression for all those looking for it. Currently fairly stable.

MinifyJS - A JavaScript minifier written in PHP

Because there was no JS minifier written in PHP available that could do optimisation of variables, and other (sometimes extreme and complex) transformations, I decided to write my own. Using the parser and tokenizer ported from Narcissus by Tino from tweakers.net, I created a simple system based on an AST which could easily handle all transformations.

How do I use it?

In the root folder there is a PHP file called min.php. It has the execute bit set and contains the shebang neccessary. ./min.php jquery-1.7.2.js does the trick.

There are various flags you can use, which will impact MinifyJS in some way:

• --no-mangle or -nm: Do not optimise variables

• --no-crush-bool or -ncb: Do not transform true to !0 or false to !1

• --unsafe or -us: Perform possibly unsafe transformations. Almost always safe

• --beautify or -b: Instead of minifying, beautify the code. Comments are still lost, except for license blocks

• --no-copyright or -nc: Also remove license blocks (/*! ... */)

• --strip-debug or -sd: Strip calls using the console variable, and remove debugger statements

• --no-inlining or -ni: Do not inline constant variables (var a = 5;alert(a); will not transform to alert(5))

• --timer or -t: Instead of showing the minified version, show various timing statistics

What kind of optimisations are done?

A lot. A few things:

• Variables are minified when not global.
• Constant folding: alert(5 + 5 / 2) will become alert(7.5). Only when the result is smaller than the original.
• Inlining
• Removal of useless statements.
• if (foo) bar => foo&&bar and other similar stuff.
• Constant if statements are replaced by either the then or else (depending on the condition)
• Same with while, for statements and alike.
• Unused variables and named functions are removed

Why?

The initial payload sent by a website is often on a clean cache. This basically means that people will have to download all content you send for your page. By minifying as much as you can, the page will be at the client faster. MinifyJS attempts to create not only smaller, but also faster JavaScript.

minifyjs's Issues

Establish a code review policy

The project could benefit for a code review policy so that, should there be reviewers available, no unreviewed code would enter the master branch (cf. the Closure Compiler). One could think of taking advantage of Git's GPG signing capabilities (also when it comes to tagging). With such a policy in place, the project could call for volunteers willing to review the code.

Write guidelines and a template for reporting defects

It could be beneficial for developers and users if guidelines and a template for reporting defects would exist. Existing work could be used, e.g., Symfony's or the Closure Compiler's.

Establish contributor guidelines

Contributor guidelines could help external developers in writing patches that would have higher chances of becoming accepted and core developers in evaluating and integrating such patches. Existing contributor guidelines (e.g. Symfony's) and other documents (e.g. A Note about Git Commit Messages) could be used.

Add option to _not_ drop unused functions/variables.

By default closure compiler doesn't do this and thus I'd imagine that this wouldn't either unless someone was doing unsafe b/c looking at just one file will lead to it dropping functions and global variables that others rely and call upon and then the code won't work anymore.

Establish a dedicated GitHub organization

Since the project be related to other projects (a Web application, a Web service, forked or frozen dependencies) in the future, one could think of creating a dedicated GitHub organization for the project. It could then be easier to find all related projects in one place (cf. jQuery, Symfony, etc.). Moreover, external developers could prefer contributing to a repository such as https://github.com/bazola/bazola over https://github.com/johnbloggs/bazola/.

List the terms on which the code is licensed

The software should list the authors of the software and the terms on which the code written by them is licensed. One could dedicate the software into public domain and use a boilerplate such as:

<?php

/*
 * Written in 2012 by Doe, John.
 * Written in 2013 by Bloggs, Joe.
 * Written in 2013 by Doe, John.
 *
 * To the extent possible under law, the author(s) have dedicated all copyright
 * and related and neighboring rights to this software to the public domain
 * worldwide. This software is distributed without any warranty.
 *
 * You should have received a copy of the CC0 Public Domain Dedication along
 * with this software. If not, see
 * <http://creativecommons.org/publicdomain/zero/1.0/>.
 */

Contributed patches would then be required to be made available under the same terms. Contributing authors would be required to add their full name to the boilerplate before their patches are accepted. If one would like to find out the impact of an author had on the software, one could use one of GitHub graphs.

External dependencies, along with their authors and licenses, should also be listed.

Employ an existing unit testing framework

It could be useful to employ an existing unit testing framework such as the PHP Unit Testing framework instead of the current solution. Benefits could include:

• code coverage analysis,
• familiarity of other developers with a unit testing framework (used in Symfony, Zend Framework 2, etc.)
• focusing on the development of the ECMAScript transformation tool instead of the development of a unit testing framework.

Impose standards with regard to the command line interface

It could be mandated to follow POSIX and GNU standards when it comes to the command line interface. This would make the software more predictable and friendly to the user.

Write a development outline

The wiki or the GitHub tracker with the milestones feature could outline of the development plans for the project. It could help developers and users understand where the project is going and what to expect in the foreseeable future (perhaps with a tentative timetable).

Make dependencies submodules

Since the project uses a Git repository, it could be useful to make dependencies its submodules instead of an integral part of the project. Even if a dependency is not available as a Git repository, it could be made one. This could improve the existing directory structure and the repository would contain an ECMAScript transformation tool only.

Composer could also be employed to manage dependencies.

Impose coding standards

Imposing and describing coding standards could lead to a readable and consistent code base and could make the process of contributing a patch easier for external developers. Existing PHP coding standards could be used (e.g. the PEAR coding standards).

Write a comparison with other tools

It could be useful if the wiki featured a comparison between MinifyJS and other tools that transform ECMAScript programs to their more compact form, e.g.:

• CKPackager,
• Closure Compiler,
• JavaScript Compression Tool for Web Applications,
• Javascript Obfuscator,
• JSMin,
• JSMin+,
• Microsoft Ajax Minifier,
• MiniME,
• Packify,
• Packer,
• Packer JavaScript en PHP,
• phpJSO,
• shrinksafe,
• UglifyJS,
• YUI Compressor.

The comparison could involve:

• availability of a command line tool,
• availability of a REST service,
• availability of a Web application,
• availability of language bindings,
• availability of source code,
• availability of source code documentation,
• availability of the tool,
• availability of user documentation,
• coding standards specified,
• company, individuals, or foundation behind the project,
• date of first release,
• date of the last update,
• ECMAScript editions supported,
• extra features (e.g. obfuscation, type checking),
• license,
• price,
• the natural language in which the documentation is written in,
• the parser used,
• the primary programming language in which the tool is written in,
• usage of code coverage analysis tools,
• usage of continuous integration,
• usage of unit tests.

Such a comparison could list supported transformations (e.g. answering which tools transform true into !0). It would be even more useful to provide an automatic unit tests for such transformations (in the manner of ECMAScript 6 compatibility table). These unit tests could be available from another repository.

The results of an automatic benchmark could also be encompassed (in the manner of Esprima: standard libraries, time, and size. Should passes be influenced by configuration, perhaps one could include the results of two configurations: one performed in the shortest time and one resulting in the shortest ECMAScript program. Such a benchmark could also make it to another repository.

Abandon PHP for ECMAScript

Since MinifyJS transforms ECMAScript, it could be argued that the tool's users are more likely to program in ECMAScript than in PHP. If PHP is abandoned for ECMAScript:

• V8 could be used to execute the code;
• the original version of the Narcissus which is available on GitHuB could be used which, since it is developed by Mozilla, is more likely to be thoroughly tested, supported, and introduce support for next editions of ECMAScript;
• Narcissus could be replaced by Esprima which is a much faster parser (cf. http://esprima.org/test/compare.html);
• tools such as falafel could be used to transform the AST;
• escodegen could either be forked or developed to generate code;
• the project could be distributed as an npm package and a replacement for UglifyJS.

In the context of transforming an AST representing an ECMAScript program, what are the advantages of PHP and its standards library in comparison to ECMAScript? Execution speed is comparable.

Not to suggest that the popularity of PHP is on a par with Common Lisp, one could compare the number of issues and pull request of the Common Lisp and the ECMAScript versions of UglifyJS.

PHP support could be provided as a language binding.

Employ continuous integration

It could be useful to take advantage of continuous integration. One could employ Travis CI for that. It is a free software solution for open source projects. It used by projects such as Symfony and Zend Framework. Benefits could include:

• knowing whether the master branch or a pull request fails for some unit tests,
• testing with different PHP versions.

Incorrect transformation of expression like -1/-0

-1/-0 is transformed into 1/-0 which leads to incorrect results, e.g.:

echo 'if (-1 / -0 < 0) throw 0;' > /tmp/test.js
./min.php /tmp/test.js > /tmp/test.min.js
v8 /tmp/test.js
v8 /tmp/test.min.js  # throws

Develop a Web service

A Web service that transforms ECMAScript programs could be developed (cf. the Closure Compiler's), perhaps in another repository.

Find "real" use-cases that fail

Describe what the tool assumes

The documentation could enumerate or explain the assumptions made by the tool with regard to the ECMAScript program being transformed (cf. the Closure Compiler). The description of how configuring the tool influences such assumptions could be beneficial.

Generate documentation

The project could use a documentation generator (such as phpDocumentor) to obtain the documentation of the code base. The comments could then follow established guidelines (e.g. PEAR's).

Not working

Hi :)
I upload it on my server but it's not working
The result is not minified
i run php 5.6
File permission problem ?
Thanks for your support
Regards

Develop a Web application

A Web application that transforms ECMAScript programs could be developed (cf. the Closure Compiler's, UglifyJS's), perhaps in another repository.

Use BCMath for calculations.

Any way to use directly from PHP?

How should I approach it if I wanted to use this directly from PHP. Using a WAMP and developing locally, so command line is not trivial to use.