Currently, I have several "environments" which are loaded using NODE_ENV
(I'm using RailwayJS / express)
development.js
app.set('mongodb_connection_string', 'mongodb://localhost/') // example
production.js:
app.set('mongodb_connection_string', process.env.MONGOLAB_URI)
So, in production, we're using the MONGOLAB_URI variable set within heroku.
Just wondering if there's a better way of managing these, without having to double up, and set app.set('mongodb_connection_string') ??
I use this really tiny module for that. It's written in coffee-script if you can't read it let me know and I'll translate it:
extend = (source, replacement)->
for k, v of replacement
source[k] = v
source
module.exports =
create: ->
env_settings = this[process.env.NODE_ENV]
extend this.general, env_settings
This allows me to write the following settings:
settings = require 'square-settings'
settings.general =
domain: '0.0.0.0:3000'
settings.production =
domain: 'www.somewhere.com'
module.exports = settings.create()
Everything in settings.general are the default settings. I can overwrite it for each environment by adding settings.environment.
Related
Consider the following code:
vm = require('vm');
context = vm.createContext({});
vm.runInContext("Buffer.from('abc').toString()", context);
Observe that this produces ReferenceError: Buffer is not defined as Buffer is a Node.js specific construct that Node.js has added as a Node Specific Global Object. (Note that other JS globals like Math and Array do not share this problem.) This particular problem can be solved by modifying the above code to
vm = require('vm');
context = vm.createContext({Buffer});
vm.runInContext("Buffer.from('abc').toString()", context);
However, if I want every single Node Specific Global to be imported, then it appears as though I must list them one by one. Given that Node.js adds Global objects relatively frequetly, is there a way I can pass all of Node.JS' global objects to a vm context? Alternatively, is there a programatic way to construct a list of all of Node Globals?
Note: Using global isn't consistent across different node versions: e.g. Buffer is in global for node v8 and v10 but not v12.
I got this.
const cloneGlobal = () => Object.defineProperties(
{...global},
Object.getOwnPropertyDescriptors(global)
)
Test:
> const nG = cloneGlobal()
> nG.myVar = 'a';
'a'
> myVar
Uncaught ReferenceError: myVar is not defined
> 'myVar' in global
false
> 'myVar' in nG
true
> 'Buffer' in nG
true
Edit:
add Example code for the author's example:
vm = require('vm');
const cloneGlobal = () => Object.defineProperties(
{...global},
Object.getOwnPropertyDescriptors(global)
)
context = vm.createContext(cloneGlobal());
const ret = vm.runInContext("Buffer.from('abc').toString()", context);
console.log(ret); // abc
The whole reason to use the "vm" module is to isolate the context of the running program from the code being executed.
If you want to execute arbitrary JavaScript inside the current context you can just use eval. No reason to use vm.createContext.
eval("Buffer.from('abc').toString()");
I'm working on some repo. And add refactoring to extract some functionality into class
The question is -- I prefer to use passing dependencies from outside (DI). But I see that it's not common pattern for node.js application.
So the question - is there any good examples ( links to repos ) where guys use DI for providing dependencies.
The opposite opinion is -- "We always can use proxyquire module to mock dependencies"
P.S
example for code I propose is
// use
const inst = new Cls(getDep1(), getDep2());
// where getDep1 / getDep2 provide dependencies from side modules
instead of
//Cls
const dep1 = require('dep1');
const dep2 = require('dep2');
module.exports = function Cls() {
// deps usage
}
// and
const inst = new Cls();
The question is about arguments in node.js related projects
Your example is about as clear as it gets. If you want to configure a stub/mock in a test for a class dependency without using proxyquire or mockery or some other require patcher, then you have to provide another point of entry into your code.
you could explicitly use DI like in your example:
function Cls(dep1, dep2) {
this.dep1 = dep1;
this.dep2 = dep2;
}
Which could live off by itself, then your calling code would be responsible for importing your class, configuring its dependencies, and instantiating it correctly. That way your Cls is isolated and unit testable itself.
You could also expose the dependencies that need to be handled as public properties:
const dep1 = require('dep1');
const dep2 = require('dep2');
module.exports = function Cls() {
this.dep1 = dep1;
this.dep2 = dep2;
}
That could allow the module that Cls is defined in to also contain the code that associates it with its deps, while still allowing your unit tests to easily configure Cls with mock/stub objects. This relies on requires to be side effect free :(
var cls = new Cls();
cls.dep1 = new SomeStub();
cls.dep2 = new SomeStub();
cls.exercise();
I want to use an yeoman generator inside a NodeJS project
I installed yeoman-generatorand generator-git (the generator that I want use) as locally dependency, and, at this moment my code is like this:
var env = require('yeoman-generator')();
var path = require('path');
var gitGenerator = require('generator-git');
var workingDirectory = path.join(process.cwd(), 'install_here/');
generator = env.create(gitGenerator);
obviously the last line doesn't work and doesn't generate the scaffold.
The question: How to?
Importantly, I want to stay in local dependency level!
#simon-boudrias's solution does work, but after I changed the process.chdir(), this.templatePath() and this.destinationPath() returns same path.
I could have use this.sourcePath() to tweak the template path, but having to change this to each yeoman generator is not so useful. After digging to yo-cli, I found the following works without affecting the path.
var env = require('yeoman-environment').createEnv();
env.lookup(function() {
env.run('generator-name');
});
env.create() only instantiate a generator - it doesn't run it.
To run it, you could call generator.run(). But that's not ideal.
The best way IMO would be this way:
var path = require('path');
var env = require('yeoman-generator')();
var gitGenerator = require('generator-git');
// Optionnal: look every generator in your system. That'll allow composition if needed:
// env.lookup();
env.registerStub(gitGenerator, 'git:app');
env.run('git:app');
If necessary, make sure to process.chdir() in the right directory before launching your generator.
Relevant documentation on the Yeoman Environment class can be found here: http://yeoman.io/environment/Environment.html
Also see: http://yeoman.io/authoring/integrating-yeoman.html
The yeoman-test module is also very useful if you want to pass predefined answers to your prompts. This worked for me.
var yeomanTest = require('yeoman-test');
var answers = require('from/some/file.json');
var context = yeomanTest.run(path.resolve('path/to/generator'));
context.settings.tmpdir = false; // don't run in tempdir
context.withGenerators([
'paths/to/subgenerators',
'more/of/them'
])
.withOptions({ // execute with options
'skip-install': true,
'skip-sdk': true
})
.withPrompts(answers) // answer prompts
.on('end', function () {
// do some stuff here
});
Unlike Rails, there doesn't seem to be an accepted way of loading environment specific config files in Node.js.
Currently I'm using the following:
config/development.js and config/production.js:
module.exports = {
'db': 'mongodb://127.0.0.1/example_dev',
'port': 3002
};
Followed by the following at the top of my app.js file:
var config = require('./config/' + process.env.NODE_ENV + '.js');
This pattern works pretty well, however it forces me to pass along this config file to any modules that need it. This gets kind of clunky, for instance:
var routes = require('./routes')(config);
.. and in routes/index.js:
modules.export = function(config) {
this.index = function...
this.show = function...
};
Etc, etc. The module pattern just seems to be pretty clunky when dealing with something that should be global, like configuration settings. I could require the configuration file at the top of every file that needs it as well, but that doesn't seem ideal either.
Does anyone have a best practice for including a configuration file and making it globally available?
You could just attach it to the global process object:
app.js:
var config = require('./config/' + process.env.NODE_ENV + '.js');
process.config = config;
aywhere else in your app
console.log(process.config);
Yes, it's a bit dangerous in that it can get overwritten anywhere, but it's still a pretty simple approach.
For example I want to use custom logger:
logger = require('basic-logger'),
logger.setLevel('info')
var customConfig = {
showMillis: true,
showTimestamp: true
}
var log = new logger(customConfig)
How to use this logger in other modules instead of console.log ?
Most people advise against using global variables. If you want the same logger class in different modules you can do this
logger.js
module.exports = new logger(customConfig);
foobar.js
var logger = require('./logger');
logger('barfoo');
If you do want a global variable you can do:
global.logger = new logger(customConfig);
global.myNumber; //Delclaration of the global variable - undefined
global.myNumber = 5; //Global variable initialized to value 5.
var myNumberSquared = global.myNumber * global.myNumber; //Using the global variable.
Node.js is different from client Side JavaScript when it comes to global variables. Just because you use the word var at the top of your Node.js script does not mean the variable will be accessible by all objects you require such as your 'basic-logger' .
To make something global just put the word global and a dot in front of the variable's name. So if I want company_id to be global I call it global.company_id. But be careful, global.company_id and company_id are the same thing so don't name global variable the same thing as any other variable in any other script - any other script that will be running on your server or any other place within the same code.
you can define it with using global or GLOBAL, nodejs supports both.
for e.g
global.underscore = require("underscore");
or
GLOBAL.underscore = require("underscore");
I would suggest everytime when using global check if the variable is already define by simply check
if (!global.logger){
global.logger = require('my_logger');
}
I've found it to have better performance
Global variables can be used in Node when used wisely.
Declaration of global variables in Node:
a = 10;
GLOBAL.a = 10;
global.a = 10;
All of the above commands the same actions with different syntaxes.
Use global variables when they are not about to be changed
Here an example of something that can happen when using global variables:
// app.js
a = 10; // no var or let or const means global
// users.js
app.get("/users", (req, res, next) => {
res.send(a); // 10;
});
// permissions.js
app.get("/permissions", (req, res, next) => {
a = 11; // notice that there is no previous declaration of a in the permissions.js, means we looking for the global instance of a.
res.send(a); // 11;
});
Explained:
Run users route first and receive 10;
Then run permissions route and receive 11;
Then run again the users route and receive 11 as well instead of 10;
Global variables can be overtaken!
Now think about using express and assignin res object as global.. And you end up with async error become corrupt and server is shuts down.
When to use global vars?
As I said - when var is not about to be changed.
Anyways it's more recommended that you will be using the process.env object from the config file.
If your app is written in TypeScript, try
(global as any).logger = // ...
or
Object.assign(global, { logger: // ... })
However, I will do it only when React Native's __DEV__ in testing environment.
May be following is better to avoid the if statement:
global.logger || (global.logger = require('my_logger'));