Electron's module wrapper differs from modern Node's (includes "process" and "global")

[ide]

• Electron version: 1.4.11
• Operating system: macOS 10.12.2

Expected behavior

I expected Electron to wrap JS modules in the same function wrapper as Node's. Electron defines an extra parameter ("process") which breaks code like const process = .... See Node's wrapper:

'(function (exports, require, module, __filename, __dirname) { '

https://github.com/nodejs/node/blob/0fb21df6e692bef9f55b9bfa876f3c59dc590332/lib/internal/bootstrap_node.js#L506

I tested with Node 6.0.0 & Node 7.4.0 and both use this wrapper.

Actual behavior

Electron uses a slightly different wrapper from its vendored copy of Node:

'(function (exports, require, module, __filename, __dirname, process, global) { '

https://github.com/electron/node/blob/811cfe3fcd360179d3dd436e3d80e1b045adf633/lib/internal/bootstrap_node.js#L489

How to reproduce

In a file loaded by Electron I have:

const child_process = require('child_process');
child_process.fork('./sample.js', [], {
    env: {
      ...process.env,
      ELECTRON_RUN_AS_NODE: 1,
    },
    silent: true,
});

and sample.js is:

'use strict';
const process = require('process');

and this results in the error: SyntaxError: Identifier 'process' has already been declared

[ide]

A quick fix that wouldn't require updating too much code would be to change Electron's module wrapper from:

// start
'(function (exports, require, module, __filename, __dirname, process, global) { '
// end
'}'

to:

// start
'(function (exports, require, module, __filename, __dirname, process, global) {' +
'return (function (exports, require, module, __filename, __dirname) {'
// end
'})(exports, require, module, __filename, __dirname);' +
'}'

This would allow process and global to be shadowed in the module function's scope, while still preserving the semantics for the other injected variables.

[kevinsawicki]

A quick fix that wouldn't require updating too much code would be to change Electron's module wrapper from:

This seems like a good approach to try, would you be up for creating a pull request for this?

[ide]

@kevinsawicki Sure, is it alright that the PR would touch a file under the vendored copy of Node?

[kevinsawicki]

Sure, is it alright that the PR would touch a file under the vendored copy of Node?

Yeah, you'll just want to fork the node submodule in vendor/node and make your changes in your fork.