I have setup 2 custom npm modules let say the scope name is "company". My modules a and b have the following structure:
module #company/a :
f1(x){moduleB.f2(x);}
f2(x){...}
module.exports = {f1, f2};
// cyclic dependency require
var moduleB = require('#company/b');
module #company/b :
f1(x){...}
f2(x){moduleA.f2(x);}
module.exports = {f1, f2};
// cyclic dependency require
var moduleA = require('#company/a');
When I now require module #company/a and fire f1(x), I get the following error :
TypeError: moduleB.f2 is not a function
I have correctly required the cyclic dependent modules after the export and I still get an empty object for the moduleB ...
Does anyone know what the problem is ?
I solved this by looking into the dependencies of the submodules like In my comment before a -> b -> c -> a ( last is required before module exports). So I just moved all of my company scoped modules after module.exports. Which does raise another question. Is there any disadvantage or anything to consider when moving all module initializations after module.exports ?
Related
reproduce link https://stackblitz.com/edit/node-sp5xay?file=index.mjs
Assume we have a project like this:
.
├── dep
│ ├── a.mjs
│ ├── b.js
│ └── c.js
└── entry.mjs
// entry.mjs
import { foo } from "./dep/a.mjs";
console.log(foo);
// dep/a.mjs
export * from './b.js'
// dep/b.js
module.exports = require("./c.js"); // 💯
// why this not working ❌
// const m = require("./c.js");
// module.exports = m;
// dep/c.js
exports.foo = "foo";
and we run in terminal
node entry.mjs
it's very confuse it will throw error if in dep/b.js we use:
// why this not working ❌
const m = require("./c.js");
module.exports = m;
if in dep/b.js we use:
module.exports = require("./c.js");
it will work expect!
module.exports=require have something magic? like symlink? if any docs i miss?
The origin of this problem is that I saw the vue3 source code
vue3 core source code export
module.exports=require have something magic?
Yes, it does have some magic. The problem is that you are importing a CommonJS module into an ES module. The latter require a static declaration of exported names, which the former do not provide. See the node.js documentation:
When importing CommonJS modules, the module.exports object is provided as the default export.
So just don't do export * from './b.js', rather import b from './b.js' then refer to b.foo on the CommonJS module object.
However,
For better compatibility with existing usage in the JS ecosystem, Node.js in addition attempts to determine the CommonJS named exports of every imported CommonJS module to provide them as separate ES module exports using a static analysis process.
[…]
The detection of named exports is based on common syntax patterns but does not always correctly detect named exports. In these cases, using the default import form described above can be a better option.
Named exports detection covers many common export patterns, reexport patterns and build tool and transpiler outputs. See cjs-module-lexer for the exact semantics implemented.
(emphasis mine)
And indeed,
module.exports = require("./c.js");
is one of the "reexport patterns" that is detected, but using a temporary variable
const m = require("./c.js");
module.exports = m;
is not. You just can't use named imports from a CommonJS module that does this. The proper solution to fix this is of course to rewrite the module to ESM syntax and use export * from "./c.js";, not any module.exports assignments.
In Node.js, the module.exports object is used to specify what a module should make available when it is imported using require.
The first statement , module.exports = require('module'), sets the module.exports object to the value of the module object that is imported using require. This means that anything that is exported by the module module will be made available to the code that imports it.
On the other hand, module.exports = {...} sets the module.exports object to an object literal containing the properties and values that should be made available to code that imports the module. This allows you to specify exactly what should be made available from the module, rather than relying on the exports of another module.
For example, suppose you have a module called myModule that exports a single function:
module.exports = {
myFunction: () => {
console.log('Hello, world!');
}
};
This module can then be imported and used like this:
const myModule = require('myModule');
myModule.myFunction(); // prints 'Hello, world!'
On the other hand, if you set module.exports to the value of another module's exports, like this:
module.exports = require('anotherModule');
Then the exports of anotherModule will be made available to code that imports myModule. For example:
const myModule = require('myModule');
myModule.someFunction(); // calls a function exported by anotherModule
I would like to ask what is the mechanism behind the commonjs/requirejs circular module dependency resovling.
Let me give you an example. Lets assume we have following module structure
modulea
index.js
submodulea_a.js
submodulea_b.js
moduleb
index.js
submoduleb_a.js
submoduleb_b.js
where modulea/index.js and moduleb/index.js just reexports interesting functionality of sub modules. i.e.:
var aa_class = require("./submodulea_a").aaclass;
var ab_class = require("./submodulea_b").abclass;
module.exports aa_class;
module.exports ab_class;
also, lets assume that in aa submodule i'll do:
var ba_class = require("moduleb").ba_class;
the same is valid for B but lets say that in submodule b I will do:
var aa_class = require("modulea").aa_class;
As you can see, there is no direct circular dependency of one class on another across modules but there is circular module dependency as modulea requires moduleb and moduleb requires modulea (better said, re-exports of something from submodules).
How this is resolved by the node commonjs or requirejs in order to avoid stack overflow? Is there something like "late binding" or whatever? I would say no as commonjs is synchronous as far as I know.
Thanks
EDIT:
So I did some research with module structure described and it seems it works similarly to the following process:
Resolve module name (package.json, node_modules, relative paths...)
Load the module code (.js file)
Mark the current module it is being initialized (resolved)
Prepare "empty" ( {} ) exports and publish it for the current module (other modules will use it for imports during require even if it is empty)
Process loaded module (execute it) and if require is found, resolve the module in the same way as the current one
Once the module execution is done, mark it as it is initialized (resolved)
if the module being initialized or initialized already is required to be loaded again, the cached version of its exports is used.
the problems which can't be resolved:
When circular module is about to be loaded it seems there is no way how to resolve:
var aa_class = require("modulea").aa_class;
inside of the module B as aa_class of the module A is not available at the time when it was required as initialization of module A handed over the execution to module B before the aa_class was exported from module A. So only the one thing available to module B is empty exports object from the module A. And I can't see any way to solve this what is bad because if I would like to extend the aa_class in bb_module I am lost.
Is there something like "late binding" or whatever?
With RequireJS yes there is. You could call it "late binding" or "lazy loading".
The documentation on Circular Dependencies uses this example.
//Inside b.js:
define(["require", "a"],
function(require, a) {
//"a" in this case will be null if "a" also asked for "b",
//a circular dependency.
return function(title) {
return require("a").doSomething();
}
}
);
So long as the modules aren't used on the top level of the file, you can import them after you export the current module:
a.js:
class A {
getB() { return new B() }
}
module.exports = A
const B = require('./b.js')
b.js:
class B {
getA() { return new A() }
}
module.exports = B
const A = require('./a.js')
I'm working on my first NodeJS project. I started building modules in the classical way as I read on books and over the internet.
As the project started growing I decided to split modules in small reusable pieces. That lead me to have a lot of require at the top of the file and sometime the risk to tackle circular dependencies. Moreover, this approach, doesn't really fits with testing because I had to require all the dependencies to make tests. I asked other developers a better way to solve this problem and most of them suggested me to use dependency injection with function constructor.
Suppose I have ModuleA and ModuleB,
ModuleC requires both ModuleA and ModuleB. Instead of requiring these modules an the top of the page I should pass them as argument in a constructor function.
e.g.
module.exports = function ModuleC(moduleA, moduleB) {
//module implementation here....
function doSomething() {}
return {
doSomething
}
}
the problem with this approach, that at first looked good, is that in the main entry point of the application I have to require and instantiate all the module to pass.
const ModuleA = require("./moduleA");
const ModuleB = require("./moduleB");
const ModuleC = require("./moduleC");
const moduleA = new ModuleA();
const moduleB = new ModuleB();
const moduleC = new ModuleC(moduleA, moduleB);
moduleC.doSomething();
Now with only 3 modules I had to write 7 line of code to use a function of a module. If I had 20 modules to work with the main entry point of the application would be a nightmare.
I guess this is not the best approach and even with this method, testing is not easy.
So, I ask you to suggest/explain me the best way to achieve this simple task that I'm finding, maybe harder than it is, while starting exploring the NodeJS word. Thanks.
Code re-usability can also be achieved if you put all of your codes in a single file. Creating smaller modules is not the only solution. consider the following codes written in a file allLogic.js(let).
var allFunctions = function(){ };
var allFunctionsProto = allFunctions.prototype;
allFunctionsProto.getJSONFile = function(fileName){
var that = this; //use 'that' instead of 'this'
//code to fetch json file
};
allFunctionsProto.calculateInterest = function(price){
var that = this; //use 'that' instead of 'this'
//code to calculate interest
};
allFunctionsProto.sendResponse = function(data){
var that = this; //use 'that' instead of 'this'
//code to send response
};
//similary write all of your functions here using "allFunctionsProto.<yourFunctionName>"
module.exports = new allFunctions();
Whenever I need to get any JSON file I know that the logic to get JSON file has already been written in allLogic.js file, hence I will require this module and use that as below.
var allLogic = require('../path-to-allLogic/allLogic.js');
allLogic.getJSON();
this approach is far better than creating tons of module for each work. Of course if the module gets longer you can create new module but in that case you need to consider separation of concern otherwise the circular dependency will haunt you.
As you are using you moduleA and moduleB in moduleC, if you put all of the codes from moduleA, moduleB and moduleC in a single module as I have pointed out you can reference the functions and all of the separate functions inside that module using that and those are also available after require.
Module A
│
└─ Module B (devDependency in Module A's package.json)
│
└─ Module C (dependency in Module B's package.json)
Module B is what I am developing. But I know that module C would be called in Module A with require('Module C'). And the error I am having is Cannot find module 'Module C'.
My current solution is ugly which is:
In index.js of Module B
exports.Module_C = require('Module_C) || require(path.resolve(__dirname, 'node_modules/Module_C/index');
In Module A
require('Module_B').Module_C
I am hoping there is better way to do it.
Modules are not inherited.
If you need the same module in two different places in your system, just require it in two different places.
// A.js
var C = require("./modules/c");
var B = require("./modules/b");
// B.js
var C = require("./modules/c");
module.exports = { };
// C.js
module.exports = { };
If you need to import subsections of a module, then navigate to the file (or root of the files) that you need.
// app.js
var add = require("./lib/helpers/math/add");
If you are trying to offer the functionality of multiple modules inside of one module, then what you're looking for is a service, which you will create an API for, to abstract what you want the end user to be able to do, from all of the places you need to touch, in order to do it.
Even if that service / library is basically just extending other interfaces onto its own interface.
A new instance of third-party module should be required in one of the modules.
// a
...
exports.thirdParty = require('third-party');
// b
...
exports.thirdParty = require('third-party');
// first-party
...
exports.thirdParty = requireFreshInstance('third-party');
// app.js
var assert = require('assert');
var a = require('a');
var firstParty = require('first-party');
var b = require('b');
assert(a.thirdParty === b.thirdParty);
assert(firstParty.thirdParty !== a.thirdParty);
assert(firstParty.thirdParty !== b.thirdParty);
All of the listed modules have similar package requirements,
dependencies: {
"third-party": "^1"
}
And the requirement is that it should stay intact, no tricks like "third-party": "git://..." are allowed.
Let's say the user controls only first-party module and can't modify third-party module to have a new factory method that would return a new instance.
I'm aware of the fact that third-party is cached once if the version is the same in all cases (technically it is full path to third-party that matters), most likely .thirdParty properties in all objects are equal.
How can this problem be solved in Node.js programmatically (not with package.json)?
Here is one module require-new could meet your requirement.
require-new requires a new module object.
require-new does not affect the state or behavior of require
method.
require-new has been designed to be used for module testing.
Here are sample from this module.
require('./rand.js'); // 0.697190385311842
require('./rand.js'); // 0.697190385311842
Modules are cached in a require.cache object when they are required.
require-new deletes the key value from the require.cache object associated with the module you are requesting, making the module reload:
requireNew('./rand.js'); // 0.2123227424453944
requireNew('./rand.js'); // 0.5403654584661126