Saw this style of import on Github and was wondering why it is used? What's the deal with the () in the end?
const logger = require('pino')()
vs
const logger = require('pino');
const logger = require('pino')();
is equivalent to
const loggerFn = require('pino');
const logger = loggerFn();
Does this help?
Let me give a more concrete example. Consider
foo.js
module.exports = function() {
return 1;
};
and now in some other module
const fooFn = require('foo');
// fooFn is our defined function
const foo = fooFn();
// foo is 1
versus
const foo = require('foo')();
// foo is 1
which is equivalent.
So basically with pino package when you require('pino') you get a function which you then have to call. That's how the package was designed.
To answer your question, you just need to understand what require does. When require is called, NodeJS returns the value of module.exports in the module you are requesting. In the case of pino, module.exports is equal to a function, so when you add the parenthesis to the end of the require statement, you are simply calling the function returned by require.
Related
I'm trying to test my Node module using Mocha.
The module is very small here is an example...
import { sharedFunctionA, sharedFunctionB, commonFunction } from <file>
const functionA = token => _data => sharedFunctionA(token);
const functionB = () => data => sharedFunctionB(data);
exports.doThingA = token => {
commonFunction(functionA(token));
};
exports.doThingB = () => {
commonFunction(functionB());
};
This is only a brief example but it shows what I'm trying to do.
I need to test that doThingA and doThingB pass in the correct function to the commonFunction.
I have stubbed the commonFunction and I can see that it is being called but I can't assert that the function passed in is correct.
TBH... I'm beginning to think of restructuring this entirely to pass in some sort of enum to the commonFunction and running the respective function from there.
In this case you can stub on the sharedFunctionA and sharedFunctionB and then retrieve the argument of your stub on the commonFunction and call it. Then check your other stubs are being called with the desired arguments.
I know it's tedious but it is the only way I can think of with your code.
Quick example:
const assert = require('assert')
const sinon = require('sinon')
const sharedFunctions = require('<fileWithSharedFunctions>')
const commonStub = sinon.stub(sharedFunctions, 'commonFunction')
const sharedBStub = sinon.stub(sharedFunctions, 'sharedFunctionB')
const fileToTest = require('<fileToTest>')
fileToTest.doThingB()
commonStub.getCall(0).args[0]()
assert(sharedBStub.calledOnce)
I have a module:
let xmlParser = require('./myTools').xmlParser;
function extractDataAndWrite(xmldata) {
let doc = xmlParser(xmldata);
...
}
module.exports = {
extractDataAndWrite,
};
now I want test the call of xmlParser in extractDataAndWrite:
var extractDataAndWrite = require('../services/importData.js').extractDataAndWrite;
var mytools = require('./myTools');
var sinon = require('sinon');
describe('Test extractDataAndWrite', function() {
it('call xmlParser', function(done) {
var xmlParserSpy = sinon.spy(mytools, 'xmlParser');
extractDataAndWrite("someXML");
console.log('xmlParserSpy: ' + xmlParserSpy.callCount);
done();
});
});
I expect get xmlParserSpy.callCount == 1 but it is 0!
My spy is not working, what must I change?
The problem is that when you create a spy on a function, you are replacing that function reference with a new function. That means that people that reference the old function will not use the new function. In your case, things are not working, as you wrap the exported function reference in mytools' after your own module has already referenced the old function reference.
The general techniques you need to look into are called dependency injection and link seams. The Sinon docs has a good tutorial on the latter, using proxyquire.
Essentially you would have this:
const proxyquire = require('proxyquire');
const toolsStub = createToolsStub();
const importData = proxyquire('../services/importData.js', {
'./myTools': toolsStub
});
function createToolsStub(){
return { xmlParser : sinon.stub().returns({mydoc:{foo:'bar'}};
}
Then later on in your test you could check the xmlParser for calls
assert(toolsStub.xmlParser.calledWith('arg1', 'arg2');
I'm wondering what does these require lines in NodeJs mean.
var debug = require('debug')('morgan')
var deprecate = require('depd')('morgan')
I'm going through the index.js of morgan package in NodeJs. Normally require only has one parameter (package).
require returns what ever was defined in the package. In the cases above they are functions and so the second parameter is actually calling the function. If you break it out it would look like this:
var debugFunctionFactory = require('debug');
var debug = debugFunctionFactory('morgan');
debug('this is a test debug command');
The implementation is easy if the module in question returns a function. And in the case of debug and deprecate it returns a function that returns a function:
// Module code:
module.export = function(customName) {
return function(message) {
console.log(customName + ': ' + message);
};
};
// Your code:
var foo = require('module'); // => function
var bar = foo('foobar'); // => function
bar('baz'); // "foobar: baz"
// More concisely:
var foo = require('module')('foobar'); // => function
foo('baz'); // "foobar: baz"
I don't think I quite understand how exports work in Node.js. In a bit of sample code, I noticed the exports object used in this manner:
exports = mongoose = require('mongoose')
mongoose.connect(config.db.uri)
exports = Schema = mongoose.Schema
What is happening behind the scenes when you use exports = twice like that? Looks to me like "mongoose" should not be exported. I did this quick test:
var foo
, bar
exports = foo = 'foo'
exports = bar = 'bar'
// reports 'bar' only
console.log(exports)
and the second test does overwrite the first export.
My guess is the original author of that sample code is confused about module.exports vs exports. To use the exports object, you must add properties to it like this:
exports.size = 42;
If you re-assign the exports variable to a new object, you basically lose access to the global exports object that node.js provided for you. If you do this twice or three or N times, the effect is the same. It's useless. For example: mod_b.js
var realExports = exports;
realExports.height = 42;
var exports = {};
exports.weight = 43;
And in mod_a.js
var mod_b = require('./mod_b');
console.dir(mod_b);
Run node mod_a.js and you get:
{ height: 42 }
Notice height is there but weight is not. Now, what you can do is assign module.exports to be an object, and that is the object that will be returned when another module requires your module. So you will see things like.
var x = 10;
var y = 20;
module.exports = {x: x, y: y};
Which will do what you expect. Here's some informative articles on the details.
Node.js Module – exports vs module.exports
What is the purpose of NodeJS module.exports and how do you use it?
Mastering Node
As an extension to #Peter-Lyons answer, your example is valid, your test case is incorrect.
Exporting variables like this is not recommended, but by doing that, you are exposing this variables into a global namespace.
e.g. test0.js
'use strict';
var assert = require('assert');
var test1 = require('./test1');
assert(globalVar1 === 123);
assert(globalVar2.a === 123);
test1.js -- mind the missing 'use strict';
exports = globalVar1 = 123;
exports = globalVar2 = {a:123};
Once again, it's valid, but not recommended.
Cheers.
If I have a node module (I wrote) and I want to pass it a value, I could do this:
var someValue process.env.SomeKey || '';
var someModule = require('./someModule');
someModule.setOption({ 'SomeKey' : someValue });
but it feels like I am reinventing the wheel.
Is there a better way to do this or is it totally subjective?
In general, you simply export a function from the module:
module.exports = function(opts){
return {
// module instance
};
}
then in the requiring page:
var mod = require('module')({ someOpt: 'val' });
But in reality, do it however you want. There's no set-in-stone standard.
I generally build modules that have similar components, sometimes just one class, or even just a selections of methods.
(function () {
var myClass = function (opts) {
this.opts = opts;
};
myClass.prototype.blah = function () {
console.log('blah');
};
exports.myClass = myClass;
})();
Then in your file that is using that module.
var mymodule = require('./mymodule');
var myInstance = new mymodule.myClass({opt1: 'blah'});
myInstance.blah();
Of course you don't need to just pass around an object of options :)
Yes, it is totally subjective.
Doing it the way you demonstrated is fine. You can also just export a function or a class by assigning it to module.exports.