Validating Strict Mode

Strict mode of JavaScript is useful to catch common mistakes, especially from someone new to the language. To get familiarized with strict mode, a real-time online validator can be useful. Such a validator spots all possible strict mode violations which can be detected at parsing time.

Esprima, the standard-compliant ECMAScript parser I am working on, has full support for strict mode. I already wrote about the use of Esprima to detect strict mode problems. Since then, I have added some improvements so that Esprima does not stop immediately on the first strict mode issue. This is done as part of Esprima tolerant parsing feature (see issue 228).

Let’s have a look at the following code fragment.

function f() {
  'use strict';
  var a = 021;
  var b = function (eval) {}
  var c = function (arguments) {}
  function d(foo, foo) {}
  function e(eval, arguments) {}
  function eval() {}
  function arguments() {}
  function interface(){}
  with (x) { }
  try { eval++; } catch (arguments) {}
  return { x: 1, y: 2, x: 1 }
}

Using Esprima’s online syntax validator, you will get tons of warnings for every single line in that function for various restrictions because you can’t do any of the following

use with statement

use octal literal

use eval or arguments as variable, function name, or function parameter

use eval or arguments as a variable in a catch clause

use reserved words, e.g. interface, as variable or function name

modify eval or arguments (with an assignment, prefix, or postfix)

have duplicated parameter names in a function

have duplicated setters, getters, or property names in an object

Thanks to the tolerant mode of Esprima, it does not stop right away after locating the first issue. You can witness how the parser attempts to continue as far as it can (in this case, until the end of the code) and then reports all its finding.

Obviously, there are strict mode violations which will be triggered at run-time only. Here is an example:

function createMonster(){
  'use strict';
  function Monster(p) {
    this.power = p;
  }
  return Monster(42);
}

The above snippet is a syntactically correct code. However, if you call function f, what happens is:

TypeError: Cannot set property ‘power’ of undefined

It is because this inside function g is bound to undefined. With strict mode, undefined this does not become the global object anymore. As a comparison, remove the strict directive and the call happily finishes, although it sets power at the global level, e.g window.power in a browser environment. This is likely not what you want, the mistake here is due to the missing new when constructing the Monster object.

In the above scenario, it is impossible for a parser to spot the problem. The actual value of this within the function invocation depends heavily on how the code gets executed, something not predictable upfront.

While run-time strict mode issues may occur, it is definitely a good idea to protect yourself as early as possible by eliminating all the parsing-time problems. I believe that any future JavaScript tools should not treat strict mode as a second-class citizen. And if you are not yet using strict mode because it is still mysterious to you, I hope Esprima online validator can give some useful immediate feedback as you sanitize your code.