Question on Javascript static analysis tool like Google Closure , JSHint , JSLint - javascript

Can A Javascript static analysis tool like Google Closure , JSHint , JSLint do the following :
Can they identify unused Javascript files and functions in the source code ?
Can they identify duplicate Javascript files and functions in the source code ?

These static analysis tools have no concept of files, only the textual representation of code. So they do not identify unused or duplicate files. They would have to have knowledge about how you deploy the files in order to do that.
They do not identify unused functions.
They do identify duplicate functions in the same file. At least in most cases:
function a() {}
/* ... */
function a() {}
will give you a is already defined. However:
var a;
a = function () {};
/* ... */
a = function () {};
is perfectly legal, and will not give you an error.
If you want to find duplicate functions in all your files, you can simply concatenate them together before linting.

Our CloneDR static analysis tool will find exact and near-duplicate copies of arbitrary code fragments for many languages, including JavaScript. It will do so within and across files. (CloneDR does not detect unused code.)

Related

Google V8 source - percentage char (%) before function javascript [duplicate]

Browsing the v8 tree, under the src directory, some js files were there, providing some basic JS objects like Math, Array etc. Browsing those files, I saw identifiers including a percent sign (%) in their names, i.e. %Foo. I first naively thought it was some other allowed character in JS's identifiers, but when I tried it in shell, it yelled at me, saying that I'm violating syntax rules. But if it is a syntax error, how come d8 works? Here are an example from the actual source code:
src/apinatives.js lines 44 to 47, git clone from github/v8/v8
function Instantiate(data, name) {
if (!%IsTemplate(data)) return data;
var tag = %GetTemplateField(data, kApiTagOffset);
switch (tag) {
src/apinatives.js lines 41 to 43, git clone from github/v8/v8
function SetConstructor() {
if (%_IsConstructCall()) {
%SetInitialize(this);
How come this identifiers do not yield syntax errors. All js files, including math.js and string.js and all others?:wq
It is not technically valid JavaScript. These are calls to V8 runtime functions. From that page:
Much of the JavaScript library is implemented in JavaScript code
itself, using a minimal set of C++ runtime functions callable from
JavaScript. Some of these are called using names that start with %,
and using the flag "--allow-natives-syntax". Others are only called by
code generated by the code generators, and are not visible in JS, even
using the % syntax.
If you look in parser.cc you can see some code relating to allow_natives_syntax that determines whether the parser will accept this extension to the JavaScript language that V8 is using to interact with its runtime. These files must be parsed with that option enabled.
I would speculate that V8 does not allow you to make these calls by default both because it would contradict the JavaScript standard and because it would probably allow you to do things to the runtime you should not be able to do.

Closure compiler: How to declare object and all of its properties as extern?

I'm trying to compile my Google Chrome extension which makes use chrome.i18n.getMessage() and a couple of other chrome properties.
I'm compiling using the Java library and have a externs.js file that I am including with the --externs parameters
I'm wondering whether or not it's possible to declare chrome as an extern, without having to specify all the properties I want to preserver?
I've tried the following 3 approaches so far:
Example 1:
/** #const */
var chrome = {}; // chrome.i18n.getMessage() gets renamed to chrome.a.b()
Example 2:
/** #const */
window.chrome = {}; // chrome.i18n.getMessage() gets renamed to chrome.a.b()
Example 3:
/* chrome.i18n.getMessage() is preserved, but chrome.runtime.connect() is renamed
* to chrome.b.c()
*/
var chrome = {
i18n: {
getMessage: function(){}
}
};
I went with the third example while fixing bugs introduced after compiling and eventually ran into some difficulties while defining more and more properties of chrome. My thought then was to see if someone else created an extern file for chrome which lead me to Googles source for the Closure Compiler. Google has been nice enough to create externs files for several well known libraries:
https://code.google.com/p/closure-compiler/source/browse/#git%2Fexterns
https://code.google.com/p/closure-compiler/source/browse/#git%2Fcontrib%2Fexterns
Closure Compiler Externs Extractor might also be useful, if your library is not listed above:
http://www.dotnetwise.com/Code/Externs/index.html
Looking through contrib/externs/chrome_extensions.js the answer to my question seems to be: You can't.
Looks like everything (or at least the parts you are calling into) need to be explicitly defined in the externs file, to be certain no renaming is performed.

How to allow minimifying of public functions names in Javascript?

I don't know whether there is a solution to this issue, but I have a large set of Javascript functions bearing long descriptive names, something like:
function getTimeFromTimezoneInMilliseconds(...) { ... };
function computeDifferenceFromUTCInMilliseconds(...) { ... };
...
These long names help explaining what the code does, since some operations are complex and not obvious to understand when reading the code only. It helps maintaining the code too.
I am minimifying this Javascript code, but of course, those names are not minimified.
Is there a refactoring trick in Javascript that would allow minimifiers to pick smaller function names and reduce the code size?
You should wrap your code in an IIFE.
This way, you won't have any public members at all, and the minifier will be able to do whatever it wants.
This has the added advantage of not polluting the global scope.
Don't minify yourself! Let the machine do the hard parts.
There are many different options.
You can use an online site where you paste your code and you get the minified back (manual).
You can automate and use a server-side language to minify your JavaScript.
You can use Google CC or Yahoo YUI Compressor to minify and greatly optimize your code.

Approaches to modular client-side Javascript without namespace pollution

I'm writing client-side code and would like to write multiple, modular JS files that can interact while preventing global namespace pollution.
index.html
<script src="util.js"></script>
<script src="index.js"></script>
util.js
(function() {
var helper() {
// Performs some useful utility operation
}
});
index.js
(function () {
console.log("Loaded index.js script");
helper();
console.log("Done with execution.");
})
This code nicely keeps utility functions in a separate file and does not pollute the global namespace. However, the helper utility function will not be executed because 'helper' exists inside a separate anonymous function namespace.
One alternative approach involves placing all JS code inside one file or using a single variable in the global namespace like so:
var util_ns = {
helper: function() {
// Performs some useful utility operation.
},
etc.
}
Both these approaches have cons in terms of modularity and clean namespacing.
I'm used to working (server-side) in Node.js land where I can 'require' one Javascript file inside another, effectively injecting the util.js bindings into the index.js namespace.
I'd like to do something similar here (but client-side) that would allow code to be written in separate modular files while not creating any variables in the global namespace while allowing access to other modules (i.e. like a utility module).
Is this doable in a simple way (without libraries, etc)?
If not, in the realm of making client-side JS behave more like Node and npm, I'm aware of the existence of requireJS, browserify, AMD, and commonJS standardization attempts. However, I'm not sure of the pros and cons and actual usage of each.
I would strongly recommend you to go ahead with RequireJS.
The modules support approach (without requires/dependencies):
// moduleA.js
var MyApplication = (function(app) {
app.util = app.util || {};
app.util.hypotenuse = function(a, b) {
return Math.sqrt(a * a + b * b);
};
return app;
})(MyApplication || {});
// ----------
// moduleB.js
var MyApplication = (function(app) {
app.util = app.util || {};
app.util.area = function(a, b) {
return a * b / 2;
};
return app;
})(MyApplication || {});
// ----------
// index.js - here you have to include both moduleA and moduleB manually
// or write some loader
var a = 3,
b = 4;
console.log('Hypotenuse: ', MyApplication.util.hypotenuse(a, b));
console.log('Area: ', MyApplication.util.area(a, b));
Here you're creating only one global variable (namespace) MyApplication, all other stuff is "nested" into it.
Fiddle - http://jsfiddle.net/f0t0n/hmbb7/
**One more approach that I used earlier in my projects - https://gist.github.com/4133310
But anyway I threw out all that stuff when started to use RequireJS.*
You should check out browserify, which will process a modular JavaScript project into a single file. You can use require in it as you do in node.
It even gives a bunch of the node.js libs like url, http and crypto.
ADDITION: In my opinion, the pro of browserify is that it is simply to use and requires no own code - you can even use your already written node.js code with it. There's no boilerplate code or code change necessary at all, and it's as CommonJS-compliant as node.js is. It outputs a single .js that allows you to use require in your website code, too.
There are two cons to this, IMHO: First is that two files that were compiled by browserify can override their require functions if they are included in the same website code, so you have to be careful there. Another is of course you have to run browserify every time to make change to the code. And of course, the module system code is always part of your compiled file.
I strongly suggest you try a build tool.
Build tools will allow you to have different files (even in different folders) when developing, and concatenating them at the end for debugging, testing or production. Even better, you won't need to add a library to your project, the build tool resides in different files and are not included in your release version.
I use GruntJS, and basically it works like this. Suppose you have your util.js and index.js (which needs the helper object to be defined), both inside a js directory. You can develop both separately, and then concatenate both to an app.js file in the dist directory that will be loaded by your html. In Grunt you can specify something like:
concat: {
app: {
src: ['js/util.js', 'js/index.js'],
dest: 'dist/app.js'
}
}
Which will automatically create the concatenation of the files. Additionally, you can minify them, lint them, and make any process you want to them too. You can also have them in completely different directories and still end up with one file packaged with your code in the right order. You can even trigger the process every time you save a file to save time.
At the end, from HTML, you would only have to reference one file:
<script src="dist/app.js"></script>
Adding a file that resides in a different directory is very easy:
concat: {
app: {
src: ['js/util.js', 'js/index.js', 'js/helpers/date/whatever.js'],
dest: 'dist/app.js'
}
}
And your html will still only reference one file.
Some other available tools that do the same are Brunch and Yeoman.
-------- EDIT -----------
Require JS (and some alternatives, such as Head JS) is a very popular AMD (Asynchronous Module Definition) which allows to simply specify dependencies. A build tool (e.g., Grunt) on the other hand, allows managing files and adding more functionalities without relying on an external library. On some occasions you can even use both.
I think having the file dependencies / directory issues / build process separated from your code is the way to go. With build tools you have a clear view of your code and a completely separate place where you specify what to do with the files. It also provides a very scalable architecture, because it can work through structure changes or future needs (such as including LESS or CoffeeScript files).
One last point, having a single file in production also means less HTTP overhead. Remember that minimizing the number of calls to the server is important. Having multiple files is very inefficient.
Finally, this is a great article on AMD tools s build tools, worth a read.
So called "global namespace pollution" is greatly over rated as an issue. I don't know about node.js, but in a typical DOM, there are hundreds of global variables by default. Name duplication is rarely an issue where names are chosen judiciously. Adding a few using script will not make the slightest difference. Using a pattern like:
var mySpecialIdentifier = mySpecialIdentifier || {};
means adding a single variable that can be the root of all your code. You can then add modules to your heart's content, e.g.
mySpecialIdentifier.dom = {
/* add dom methods */
}
(function(global, undefined) {
if (!global.mySpecialIdentifier) global.mySpecialIdentifier = {};
/* add methods that require feature testing */
}(this));
And so on.
You can also use an "extend" function that does the testing and adding of base objects so you don't replicate that code and can add methods to base library objects easily from different files. Your library documentation should tell you if you are replicating names or functionality before it becomes an issue (and testing should tell you too).
Your entire library can use a single global variable and can be easily extended or trimmed as you see fit. Finally, you aren't dependent on any third party code to solve a fairly trivial issue.
You can do it like this:
-- main.js --
var my_ns = {};
-- util.js --
my_ns.util = {
map: function () {}
// .. etc
}
-- index.js --
my_ns.index = {
// ..
}
This way you occupy only one variable.
One way of solving this is to have your components talk to each other using a "message bus". A Message (or event) consists of a category and a payload. Components can subscribe to messages of a certain category and can publish messages. This is quite easy to implement, but there are also some out of the box-solutions out there. While this is a neat solution, it also has a great impact on the architecture of your application.
Here is an example implementation: http://pastebin.com/2KE25Par
http://brunch.io/ should be one of the simplest ways if you want to write node-like modular code in your browser without async AMD hell. With it, you’re also able to require() your templates etc, not just JS files.
There are a lot of skeletons (base applications) which you can use with it and it’s quite mature.
Check the example application https://github.com/paulmillr/ostio to see some structure. As you may notice, it’s written in coffeescript, but if you want to write in js, you can — brunch doesn’t care about langs.
I think what you want is https://github.com/component/component.
It's synchronous CommonJS just like Node.js,
it has much less overhead,
and it's written by visionmedia who wrote connect and express.

Any advanced tool to compress a JS file?

I'm looking for a tool to compress my JS files.
What I want is not just simply remove unneccessary characters;
I prefer to tool to be able to reduce the lengths of
local variables in functions also.
Even better I the tool can reduce the lengths of all other
stuff like global variables, function names, etc. This is to protect the code from being used by web viewers without our consent.
For example, the tool should rename a variable or function name from "some_variable", "some_function" to "sv", "sf", etc. And then refactoring all related references.
I've tried to dig the net but couldn't find something similar.
I think that this one can help you : http://www.minifyjavascript.com/
I've used it in the past and it does a good job!
The Google Closure Compiler does this. It has various settings, but even the "simple optimizations" setting will shorten variable names and (in cases where it knows the function will never be called outside the script) function names. It will even inline functions when there's a savings to be had.
For example, given this script:
jQuery(function($) {
var allDivsOnThePage = $("div"),
someParagraphsAsWell = $("p");
setColor(allDivsOnThePage, "blue");
setColor(someParagraphsAsWell, "green");
function setColor(elms, color) {
return elms.css("color", color);
}
});
Using the closure compiler with simple optimizations (and telling it we're using jQuery) yields:
jQuery(function(a){var b=a("div"),a=a("p");b.css("color","blue");a.css("color","green")});
Note how it's not only shortened the identifiers, but reused one where it detected it could (in this case that didn't save us anything, but in some other cases it could), and inlined the setColor function since that resulted in a savings.
Try YUI Compressor:
http://developer.yahoo.com/yui/compressor/
For me it seems to be one of the most powerful at the moment.

Categories

Resources