expose the process global through require('process'); #4493

Closed
wants to merge 1 commit into from

7 participants

@defunctzombie

This was done for the node specific buffer module a long time ago,
however process was left as a global. This allows the use of process via
a require so that going forward this can become the practice for
obtaining the process info much like buffer global was phased out.

see #4487 for some more comments on the topic.

@defunctzombie defunctzombie expose the process global through require('process');
This was done for the node specific buffer module a long time ago,
however process was left as a global. This allows the use of process via
a require so that going forward this can become the practice for
obtaining the process info much like buffer global was phased out.
5ba39e0
@bnoordhuis
Node.js Foundation member

It's the other way around, actually; Buffer used to be a require('buffer') symbol but it's a global now.

Anyway, thanks for the PR but I'm not going to take it. The current approach is not ever going to change; too much breakage for too little benefit.

@bnoordhuis bnoordhuis closed this Dec 31, 2012
@defunctzombie

It won't break things. Also, why introduce more globals if you don't have to? Sure a global is easy to use, but why not make everything a global then? In the same way good practice points to avoiding globals, I would think this would be almost a no brainer.

@dominictarr

this isn't actually gonna break anything, if you leave in the process global.

@bnoordhuis bnoordhuis reopened this Dec 31, 2012
@bnoordhuis
Node.js Foundation member

@isaacs @substack mentioned that this change helps modules like browserify. WDYT?

@aredridel

I actually really like this approach. Having the runtime's surface as minimal as possible is good for tooling.

@medikoo

Great move, it will definitely help writing cross-environment, more generic modules

@Raynos

👍

This will allow us to

  • require process in browser modules without having process injected into modules as a free variable or process being a global
  • allow us to use mocking tools that intercept require to intercept process without patching globals.
  • please linters and OCD about minimizing globals
@isaacs

Adding a new builtin module is very annoying. Anyone using http://npm.im/process will be broken by it. There are other ways to work around all the issues brought up here.

Making process not a global is completely out of the question.

@isaacs isaacs closed this Jan 11, 2013
@defunctzombie

I am not advocating removing the global. I am advocating deprecating the use of it in favor of an explicit require. There is no reason globals should have been introduced in the first place and are harder to deal with. Especially ones that are not part of the js spec. We have a way to indicate you want library functionally require and we should be using it.

@isaacs

The process global object is not going to be deprecated. Adding a new builtin module is too costly, and it provides hardly any benefit.

I've got a long list of "should never have"s for node, but this isn't even in the top 10. This was perhaps relevant 3 years ago, but it's way too late to do now.

@Raynos

@isaacs all https://npmjs.org/package/process does is global.process = global.process || {}. It doesn't export any tokens or do anything useful

having a new builtin for process be module.exports = global.process is backcompat with that package in node.js because the module doesn't have any side effect in node and doesn't export anything.

I don't see what else makes it expensive

@isaacs

@Raynos We won't be adding any more builtin modules to node.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment