In the Node.js module system, each file is treated as a separate module. For example, consider a file named foo.js:<\/p>\n
const circle = require(‘.\/circle.js’);<\/p>\n
console.log(`The area of a circle of radius 4 is ${circle.area(4)}`);<\/p>\n
On the first line, foo.js loads the module circle.js that is in the same directory as foo.js.<\/p>\n
Here are the contents of circle.js:<\/p>\n
const { PI } = Math;<\/p>\n
exports.area = (r) => PI * r ** 2;<\/p>\n
exports.circumference = (r) => 2 * PI * r;<\/p>\n
The module circle.js has exported the functions area() and circumference(). Functions and objects are added to the root of a module by specifying additional properties on the special exports object.<\/p>\n
Variables local to the module will be private, because the module is wrapped in a function by Node.js (see module wrapper). In this example, the variable PI is private to circle.js. The module.exports property can be assigned a new value (such as a function or object). Below, bar.js makes use of the square module, which exports a Square class:<\/p>\n
const Square = require(‘.\/square.js’);<\/p>\n
const mySquare = new Square(2);<\/p>\n
console.log(`The area of mySquare is ${mySquare.area()}`);<\/p>\n
The square module is defined in square.js:<\/p>\n
\/\/ Assigning to exports will not modify module, must use module.exports<\/p>\n
module.exports = class Square {<\/p>\n
constructor(width) {<\/p>\n
this.width = width;<\/p>\n
}<\/p>\n
area() {\u00a0\u00a0\u00a0\u00a0 return this.width ** 2;\u00a0 } };<\/p>\n
The module system is implemented in the require(‘module’) module.<\/p>\n
When a file is run directly from Node.js, require.main is set to its module. That means that it is possible to determine whether a file has been run directly by testing require.main === module. For a file foo.js, this will be true if run via node foo.js, but false if run by require(‘.\/foo’).<\/p>\n
Because module provides a filename property (normally equivalent to __filename), the entry point of the current application can be obtained by checking require.main.filename.<\/p>\n
The semantics of Node.js’s require() function were designed to be general enough to support a number of reasonable directory structures. Package manager programs such as dpkg, rpm, and npm will hopefully find it possible to build native packages from Node.js modules without modification.<\/p>\n
Below we give a suggested directory structure that could work:<\/p>\n
Let’s say that we wanted to have the folder at \/usr\/lib\/node\/<some-package>\/<some-version> hold the contents of a specific version of a package.<\/p>\n
Packages can depend on one another. In order to install package foo, it may be necessary to install a specific version of package bar. The bar package may itself have dependencies, and in some cases, these may even collide or form cyclic dependencies.<\/p>\n
Since Node.js looks up the realpath of any modules it loads (that is, resolves symlinks), and then looks for their dependencies in the node_modules folders as described here, this situation is very simple to resolve with the following architecture:<\/p>\n
Thus, even if a cycle is encountered, or if there are dependency conflicts, every module will be able to get a version of its dependency that it can use.<\/p>\n
When the code in the foo package does require(‘bar’), it will get the version that is symlinked into \/usr\/lib\/node\/foo\/1.2.3\/node_modules\/bar. Then, when the code in the bar package calls require(‘quux’), it’ll get the version that is symlinked into \/usr\/lib\/node\/bar\/4.3.2\/node_modules\/quux.<\/p>\n
Furthermore, to make the module lookup process even more optimal, rather than putting packages directly in \/usr\/lib\/node, we could put them in \/usr\/lib\/node_modules\/<name>\/<version>. Then Node.js will not bother looking for missing dependencies in \/usr\/node_modules or \/node_modules.<\/p>\n
In order to make modules available to the Node.js REPL, it might be useful to also add the \/usr\/lib\/node_modules folder to the $NODE_PATH environment variable. Since the module lookups using node_modules folders are all relative, and based on the real path of the files making the calls to require(), the packages themselves can be anywhere.<\/p>\n
To get the exact filename that will be loaded when require() is called, use the require.resolve() function. Putting together all of the above, here is the high-level algorithm in pseudocode of what require.resolve() does:<\/p>\n
require(X) from module at path Y<\/p>\n
LOAD_AS_FILE(X)<\/p>\n
LOAD_INDEX(X)<\/p>\n
LOAD_AS_DIRECTORY(X)<\/p>\n
<\/p>\n
LOAD_NODE_MODULES(X, START)<\/p>\n
NODE_MODULES_PATHS(START)<\/p>\n
In the Node.js module system, each file is treated as a separate module. For example, consider a file named foo.js: const circle = require(‘.\/circle.js’); console.log(`The area of a circle of radius 4 is ${circle.area(4)}`); On the first line, foo.js loads the module circle.js that is in the same directory as foo.js. Here are the contents…<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"categories":[8453],"tags":[8327],"class_list":["post-72655","page","type-page","status-publish","hentry","category-node-js","tag-module-basics"],"acf":[],"yoast_head":"\n