Make `process` requireable

[andrewdeandrade]

Ideally (IMHO) there would be no globals besides the 4 node keywords required for the module system to function: require, module, __dirname and __filename.

For many of the other modules that are typically globals, you can require them out of the box, such as

var console = require('console');
var setTimeout = require('timers').setTimeout; // same with clearTimeout, setInterval and clearInterval
var Buffer = require('buffer');
// etc...

One of the few standard parts of node that cannot be loaded via require() is process.

The popularity of this npm module: https://www.npmjs.com/package/process , with almost a million downloads in the last month shows that a lot of people would benefit from having process be requireable. By making it requireable, browserify can then treat it as one of the special compatibility modules and list it here: https://github.com/substack/node-browserify#compatibility

[ibc]

+1

[lxe]

[chrisdickinson]

I don't see any downsides to this, but not any particular upsides either: browserify is likely going to have to check for implicit globals like process for a long time.

I'm +0 on a PR for this -- if one is submitted, and no other TC member has strong feelings about this, I'd be happy to shepherd it.

[bodokaiser]

+1

[ralphtheninja]

Cool

[buschtoens]

This would render a few npm packages incompatible. But those could easily and automatically be updated with a PR-bot.

I really like this idea. Globals always felt wrong for me.

What about standard primitives tho?

[andrewdeandrade]

@buschtoens FWIW the lint rules we use in uber/lint-trap only allow four globals (which I mentioned in my post at the top of this page) whether you are on nodejs or in the browser with browserify. For the browser stuff, we recommend that people use https://github.com/Raynos/global

The great thing about making everything requireable is that it makes it easy for people to mock out fakes when testing since all references in a file point to a closured var that can be overwritten just like substack does with fs here: https://github.com/substack/node-mkdirp/blob/master/test/opts_fs.js#L16

Besides process and global, I think all the other standard primitives are already requireable. For all the timers, you have the timers module. For buffers, the buffer module, etc.

I'm not in favor of implementing this in a way that breaks backwards compatibility (i.e. you should still be able to refer to process as a global, but you can also require it in instead if you prefer). Keeping the standard primitives from being called as a global really is the responsibility of your linter.

[andrewdeandrade]

@chrisdickinson I've never committed to nodejs or iojs, but I'm open to forking and creating a PR for this if you can just give me a few sentences explaining what parts of the source I should look into to figure out how to go about adding this feature. Just knowing where to start helps a lot.

[brendanashworth]

I have to disagree with a change such as this. In my opinion, it inherently goes against the idea of a module system and a system process.

The built-in modules (such as http, tls, fs, events, util...) are a set of separable, standalone libraries that can be used to build an application on top of a running system process. Should the process global variable be namespaced into a module, it would be categorized as a library (like the other available modules), which is practically a lie to end users. This would turn process into an anti pattern.

The only reason functions like setTimeout and setInterval are attached to global is because they are part of the JavaScript specification. As you stated earlier, you'd like the only four global variables to be the ones required to make the module system function. But do we really need an entire module to tell us the pid? The file descriptor of stdin? Or would it be simpler to use a global variable, not break previous modules, and stay true to the inherent design of a program?

[Raynos]

We would not remove the global.

Process will always be global. You can just require it as a primary interface. However it has to be global, we cant break back compat.

[brendanashworth]

@Raynos yes, but I still disagree on the basis of it being categorized with the rest of the modules.

[lxe]

Why not just make require('process') do a noop instead of actually loading a module? You can have the best of both worlds. It's just as much of a hack as making process global in the first place.

Just like Buffer:

require('buffer').Buffer === Buffer // true!

Node io.js is already full of these inconsistencies, and making process behave the same way is a good acceptable idea.

[feross]

+1

[seishun]

Can someone explain why this is a good idea? As in, a real-world scenario that would benefit from this?

[andrewdeandrade]

There are a couple of benefits:

(1) establishes a pointer reference more deeply in the scope chain. when process is required in, any references to process will be resolved in that file instead of going up the scope chain.
(2) makes testing easier. because you have a variable declaration in the file you can expose an option for redeclaring what it points to just like substack does in this test with fs. https://github.com/substack/node-mkdirp/blob/master/test/opts_fs.js . when unit-testing, being able to inject the process.env option you need for that file over the process.env you have in testing.
(3) no more need for requiring a third-party process module when you want process.nextTick available with browserify. Every other native node primitive can be supplied by the module system. Would be nice if you could do the same with process.
(4) some people prefer to declare every token they use in a file, except for the language primitives and keywords.

There was another benefit I thought about this morning, but I can't remember it right now.