Develop Reference

Javascript - Find all implicitly declared variables in directory?

I have 100+ js files in a directory in atom editor. In chrome console I get errors about many variables not being defined (only the ones I interact with on the page are the ones that show they are undefined), but the error goes away and that portion of js works when I add the var/const/let keyword before those variables.
I now understand that they are implicitly implied variables because throughout the files, some are defined like this (strict mode is on):
foo = bar; // This is an implicitly implied variable
var foo = bar; // This fixes the issue
So the solution is to add var/const/let before those variables, but I am wondering if there is any way to scan the directory of files to point out the implicitly implied variables so I can add var/const/let in front of them?
It is taking very long to navigate through all the files manually scanning for those variables to fix up or navigate the app and wait for the error to show up to fix it one by one.
Any quick solution for this (without disabling strict mode)?

You could use a linter for the directory, which will browse through all the files and raise warnings.
JSHint is a popular one, and it's pretty easy to get going with npm from the command line, or you can install it into your code editor like Atom or Sublime.
The CLI version will be more powerful, you can specify a directory for it to scan, and recursively scan all children. In your code editor, you'll usually only get warnings for the file you currently have open.

Reading Open Source: a series of IIFEs

I've been reading the Medium.js Open Source Project that tries to mock Medium.com.
While reading, I noticed a pattern in the code. Mainly, an IIFE is called every so often to do a variety of stuff.
(function(Medium) {
"use strict";
//do stuff
})(Medium);
(function(Medium) {
"use strict";
//do stuff
})(Medium);
(function(Medium) {
"use strict";
//do stuff
etc.
Why is the code compartmentalized like this? Couldn't it all be invoked at the same time, why call a series of IFFE statements? Is this a common pattern? You can view my link above for the full code I am referring to.

If you look through the source files, you will see that each individual component is developed in a separate JavaScript file. A build script is used to concatenate all of these scripts together, and produce the file you are looking at.
By developing it this way, you could build your own custom build with only the components you need. By wrapping groups of functions together in an IIFE, he can also avoid setting "use strict" globally, and for each individual function. If there was a need to a variable to be shaded between a set of API's, this allows a variable to be declared inside the IIFE, without colliding with variables in other modules or the global space.
But the main advantage is the developer can develop the library as multiple different files, and you can optionally only include those you need in your project.

If you look in the src/Medium directory you can see that each of these IIFE's are separate files and many of them have matching files in the tests directory.
They separate their code like this so they can split their code up into small testable modules and they use IIFE's to extend an existin Medium object with new functionality.
The Medium.js file is a result of a build process that concatinates all the files in the src/Medium folder.

Loading jQuery inside an ES5 strict mode function

I'd like to import jQuery inside an IIFE scope like this:
(function (window, document) {
"use strict";
/* Content of jquery.min.js goes here */
/* Code that uses $ goes here */
}(window, document));
Now, I'm running into a strict mode violation as soon as this code runs, possibly because jQuery itself doesn't conform:
In strict mode code, functions may be declared only at top level or
immediately within another function.
Is there a way to load jQuery just inside a single function scope, while still retaining strict mode for the rest of the code that relies on it?

Answered here: https://github.com/jquery/jquery/issues/1779
jQuery isn't meant to be run with "use strict" in effect. See the comment at the top of the unminified file for the reason, or look at http://bugs.jquery.com/ticket/13335 for more information. You are not gaining anything by attempting to force jQuery into strict mode against its will, doing so prevents interoperability with any third-party libraries that are not use-strict compatible.

What "use asm" does exactly?

As far as I know, Asm.js is just a strict specification of JavaScript, it uses the JavaScript features and it's not a new language.
For instance, instead of using var a = e;, it offers var a = e|0;.
My question is, if asm.js is just a definition and can be achieved by changing the way one uses and declares variables and dynamic types, what does "use asm"; actually do? Is this necessary to put this string before declaring function's body or not?

Asm.js is a very strict subset of JavaScript, that is optimized for machines rather than humans. If you want your browser to interpret certain code as asm.js code, you need to create a module wherein the following conditions apply :
all code is fully statically typed and limited to the very restrictive asm.js subset of JavaScript
your module starts with the "use asm" pragma
Additionally, an asm.js module allows only up to three optional yet very specific parameters :
a standard library object, providing access to a subset of the JavaScript standard libraries
a foreign function interface (FFI), providing access to custom external JavaScript functions
a heap buffer, providing a single ArrayBuffer to act as the asm.js heap
So, your module should basically look like this :
function MyAsmModule(stdlib, foreign, heap) {
"use asm";
// module body...
return {
export1: f1,
export2: f2,
// ...
};
}
The function parameters of your module allow asm.js to call into external JavaScript and to share its heap buffer with "normal" JavaScript. The exports object returned from the module allows external JavaScript to call into asm.js.
Leave out the "use asm", and your browser will not know that it should interpret your code as an asm.js module. It will treat your code as "ordinary" JavaScript. However, just using "use asm" is not enough for your code to be interpreted as asm.js. Fail to meet any of the other criteria mentioned hereabove, and your code will be also interpreted as "ordinary" JavaScript :
For more info on asm.js, see eg. John Resig's article from 2013 or the official specs.

"use asm" is a pragma that tells the JavaScript engine specifically how to interpret it. Although it's valid JavaScript and can be used without the pragma, FireFox can perform additional optimizations to the Asm.js subset to increase performance. To do this, it must know that it is Asm.js.

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

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.)