More fun with scopes and ScriptObjectMirror

[Attila Szegedi]

On Dec 11, 2013, at 3:08 PM, Tim Fox <timvolpe at gmail.com> wrote:

> On 11/12/13 13:50, Attila Szegedi wrote:
>> On Dec 11, 2013, at 2:22 PM, Tim Fox <timvolpe at gmail.com> wrote:
>> 
>>> On 11/12/13 13:19, A. Sundararajan wrote:
>>>> The way Avatar/js project ( https://java.net/projects/avatar-js ) project implements CommonJS/require is as follows.
>>>> 
>>>> It creates a anonymous function code wrapping a module (say like http.js). The anonymous function accepts 'exports' as argument. When you eval that code at top level global scope, because of the anon function wrapping around, all top level vars in a module code like http.js become locals of that anon function.
>>> Isn't that the same as what I described in my last post?
>>> 
>>> If so, the problem with that is that globals that aren't prefixed with var still leak.
>> I might be mistaken, but isn't that the best technique browser-based (pure JavaScript) require() implementations can do too? Again, not justifying the design (I'm saying this a lot today), just pointing out that a widespread deployment base - namely, all browsers - might also suffer from the problem.
> tbh I don't think CommonJS is used much in browsers, but most probably any browser implementation would have the same issue with non var globals leaking too.
> 
> Having said that it should be possible to get around the leaking non var global issue even using a pure JS require.
> 
> If you pre-parsed the JavaScript before executing it (would need a JS parser written in JS for this, e.g. JSLint), you could, I guess prefix any non var globals with a namespace, e.g.
> 
> myglobal = 123;
> 
> function foo() {
>   return myglobal;
> }
> 
> would be transformed to:
> 
> somenamespace.myglobal = 123;
> 
> function foo() {
>  return somenamespace.myglobal
> }
> 
> Where somenamespace could be generated using a random UUID or such-like.
> 

You can also prevent modules that assign to new globals from loading by forcing a strict eval:

function loadModule(src) {
    "use strict";

    var _exports = {};
    eval("(function(exports){" + src + "})(_exports)");
    return _exports;
}

With this function

	loadModule("x = 1")

will throw a ReferenceError. 

	var m = loadModule("var x = 2; exports.f = function() { return x }")

on the other hand will work, and m.f() will print 2.

Of course, this doesn't prevent the module script from modifying an _existing_ global, but this is as far as we can get.

Attila.