How is setting an environment variable like process.env.thing = 42 different from creating a global variable like global.thing = 42?
When would prefer process.env.thing over global? What are the pros/cons of both objects?
global is the global object. process is available globally, because it is a property of global. In fact:
global.process === process //-> true
process.env has properties set to the environment variables of the system. These can be set a variety of ways outside of node itself, and read in by accessing properties of process.env.
At the command line try:
FOO=bar node -e "process.env.FOO"
The process module is just a globally available thing.
The choice in my opinion must be something like this.
1)If the variable depends on the environment it must be set in process.env
2)If the variable is just a constant that is accessible from the entire application it must be set to global.
I think if you don't face these 2 points you don't have a need to store some value in both
If you start your node.js application you may want to use some different "environments", like API-URLs and stuff like this, because in a production / live environment those URLs are usually different in comparision to your local development environment.
This means that you can inject those paths using a .env file for example BEFORE starting your application.
This is an example:
NODE_API_URL=https://myApi.com/myEndpoints myApp.js
The global.thing = bla line will be read after the environment variables were set.
Once the application is running the environment variables and the other global definitions can be accessed by the app.
from the docs NodeAPI
The process object is a global that provides information about, and
control over, the current Node.js process. As a global, it is always
available to Node.js applications without using require().
You want to attach your environment variables to this object to make sure that there is no other pollution of globals.
Related
I saw some people use app.locals to store properties that is available across all views.
Also other people used global.AnyNameVariable to store anything even like requiring config.js files and etc
ex:
app.locals.objOne = {
name:'John'
}
global.objTwo = {
name:'Doe'
}
What is the difference between them? and what is the purpose? what is the right way to use both?
As the documentation states,
The app.locals object has properties that are local variables within the application.
This is application-level container provided by the framework that serves to store application settings, etc. There can be more than one Express application, while global is global.
app.locals is available as req.app.locals within middlewares, this way it can be decoupled from specific app variable.
This code:
https://github.com/bjornharrtell/jsts/blob/master/index.js
refers to a variable named "GLOBAL".
When I run this in a browser, I get an error message:
"ReferenceError: GLOBAL is not defined"
Where does this GLOBAL come from, and why is it not defined?
In Node.js, GLOBAL is an alias to the global object (more commonly referred to as global).
In browsers, it doesn't exist.
Browserify recognizes the global alias, and will inject a reference to window, but does not recognize GLOBAL.
It was changed to global four years ago
Global variable came from the implementation of javascript in nodeJS
You can see it as Windows object for implementation of javascript in a web browser
The code you are looking at is designed to run in a Node.JS environment.
The GLOBAL variable is documented in the node manual.
It is a feature provided by the Node environment and not a core part of JavaScript.
Are there any security issuses or something with using global variables and assignig modules to global variables in nodejs?
example:
client = new Client();
Without the var statement, so i can use it everywhere?
It's not that it's a security problem, it's considered bad practice though and it can lead to other problems such as trying to override a Node.js global variable.
Try not to pollute the global namespace and if you really really need global variables, just use one with sub-objects.
I don't think there are security issues per se, but you will be polluting the global namespace. As your project grows (especially with more than one programmer) the risk of conflicts gets bigger. And what if you later on add a third party library to your project that has a variable named 'client'?
I've been using Node for a couple of years and I had the same "problem" you have and is frustrating. Nevertheless I can give you the solution I reached and it works for me.
Node doesn't allows global variables in the way you ask since variables defined as global in a module are global only for that module. But exists a GLOBAL object that ban be used for what you need.
Global variables are a bad idea in general (always), but having a global cache of useful functions in it's own namespace is not a crime at all since it will not override anything and lets you use it along your code. So I'll tell you what I do to share functions and objects between modules and keep source organized (that's important for me at least!):
1st Create a resource file where you place all important functions and objects you want to share across your code. I call mine "R.js", R from Resources
2st Define the "R" object that will store all functions and objects and assign it to node's GLOBAL object:
var R = {};
GLOBAL.R = R; // Adds resource module to global
3rd For sake of simplicity and avoid extra requires all arround the code, I do all needed requires inside R.js. After that you only need to use them with R.require_variable.function_or_property
// All needed requires
R.fs = require('fs');
R.net = require('net');
R.http = require('http');
R.dbClient = require('mysql').Client;
...
4th Create the shared functions, variables and objects you like inside the R object
5th Where needed arround your code, require the R.js file and access to it's member by using the R object
R.<property_or_function>
2 warning notes.
Remember to always call shared functions or user shared objects placind "R." in front of it
Althought you can assign new functions, objects and properties to R object anywhere this can lead to the same inconsistencies you would have with global variables if you don't plan it in advance - i.e. you call a shared function before assigning it to R - so as a methodology, create everything in the R.js file instead of doing it all arround your code. This way all shared things will be in R.js and that is the only place to look for shared code.
In my server.js file I included the Underscore.js library.
var _ = require('underscore')
I have my routes like this:
// require routes
require('./routes/document');
In the document route, I want to use Underscore.js. But it seems like the _ variable is not inherited/inside the document scope. Does that mean I have to set the _ variable on every single required route? Or is there a more intelligent way to do this?
Yes, you should set the _ in the files that needs it to be available.
Alternatively, you can put it in the global scope by removing the var part.
_ = require('underscore');
require('./routes/document'); // _ will be visible in document as well
Check the Node.js module documentation where require() is thoroughly explained.
http://nodejs.org/docs/v0.4.5/api/modules.html
As for your specifics:
Modules are cached after the first time they are loaded. This means (among other things) that every call to require('foo') will get exactly the same object returned, if it would resolve to the same file.
Hence, if you require('underscore') in both your parent library and './routes/document', only one instance of the underscore module will be loaded and hence. Both variables will be in fact the same object.
And by the way, you don't want to define variables in the global scope as it might generates side effects and potentially overwrite properties in other modules.
Finally, the util module provides an inherits method to subclass another constructor and inherit from its prototypes.
http://nodejs.org/docs/v0.4.5/api/util.html#util.inherits
As far as I know Node.js engine "requires/charges" a module/file.js in a different scope (I don't know exactly how), for security reasons (imagine a module could change the variables were it's required. That would be dangerous! More information about this concern: Information hiding).
The only exception are global Node.js objects that are exposed into the module scope.
A global object is, precisely the object "global", and everything you define without var keyword actually is added to that global object:
foo_var = "Whatever"
means that:
console.log(global.foo_var) // Logs "Whatever"
I know that global variables are bad.
But if I am using node's module "util" in 40 files in my framework, isn't it better to just declare it as a global variable like:
util = require('util');
in the index.js file instead of writing that line in 40 files?
Cause I often use the same 5-10 modules in each file, that would save a lot of time instead of copy paste all the time.
Isn't DRY good in this case?
You could just have a common module.
common.js:
Common = {
util: require('util'),
fs: require('fs'),
path: require('path')
};
module.exports = Common;
app.js:
var Common = require('./common.js');
console.log(Common.util.inspect(Common));
Each module is supposed to be independent. The require doesn't cost anything anyways after the first one for each module.
What if you wanted to test one module alone? You'd be having a lot of issues because it wouldn't recognize some "global" requires that you have in your app.
Yes, globals are bad, even in this case. Globals almost always ruin: testability, encapsulation and ease of maintenance.
Updated answer Jan. 2012
The global object is now a global inside each module. So every time you assign to a global variable (no scope) inside a module, that becomes part of the global object of that module.
The global object is therefore still not global, and cannot be used as such.
Updated Dec. 2012
The global object now has the global scope within the application and can be used to store any data/functions that need to be accessed from all modules.
global.util = require('util');
There's a section about global objects in the node documentation.
However, globals should be used with care. By adding modules to the global space you reduce testability and encapsulation. But there are cases where using this method is acceptable. For example, I add functions and objects to the global namespace to use within my unit test scripts.
I'm confused by the answers in this thread.
I am able to do this...
File: test.js
global.mytest = {
x: 3,
y: function() { console.log('Works.'); }
};
File: test2.js
console.log('Does this work?');
mytest.y();
File: server.js
require('test.js');
require('test2.js');
And it seems to work as the question needed. The first require places the mytest object into the global scope, then the second require can access that object without any other qualifiers.
I was trying to figure this out (which brought me to this thread from a Google search) and I wanted to post what seems to work for me now. Maybe things have changed since the original answers.
I have successfully been using the process object for passing around my configuration object. While in theory suffering from the exact same issues as mentioned above (encapsulation, testability and so forth) it works fine when using only non-state modifying properties (a hash table with primitives, basically).
If you wrap your modules in blocks (e.g. anon functions) you can bind to a local name (via parameter or 'var') and then have any arbitrary long (perhaps "package" labeled) name you want (if you even need a global at this point).
For instance, my modules often look similar to:
;(function ($, $exp, other) {
$(...)
other.xyz()
$exp.MyExportedObject = ...;
})(jQuery, window, some_module.other_expression) // end module
I use jQuery with noConflict, this the former, and the latter show you can do this for any expression -- global, require, computed, in-line, whatever... this same "wrapping" approach can be used to eliminate all (or almost all) "special named" globals -- globals must exist at some level, however, removing potentially conflicts is a very big win.