More fun with scopes and ScriptObjectMirror

Tim Fox timvolpe at
Wed Dec 11 06:08:35 PST 2013

On 11/12/13 13:50, Attila Szegedi wrote:
> On Dec 11, 2013, at 2:22 PM, Tim Fox <timvolpe at> wrote:
>> On 11/12/13 13:19, A. Sundararajan wrote:
>>> The way Avatar/js project ( ) 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.

More information about the nashorn-dev mailing list