Italian Translation Report: Node.js [Part 32 - 1238 words]

In the Node.js module system, each file is treated as a separate module.
For example, consider a file named
On the first line, loads the module that is in the same directory as
Here are the contents of
The module has exported the functions and
Functions and objects are added to the root of a module by specifying additional properties on the special object.
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 is private to
The property can be assigned a new value (such as a function or object).
Below, makes use of the module, which exports a Square class:
The module is defined in
assigning to will not modify module, must use
The module system is implemented in the module.
Accessing the main module
When a file is run directly from Node.js, is set to its
That means that it is possible to determine whether a file has been run directly by testing
For a file, this will be if run via, but if run by
Because provides a property (normally equivalent to), the entry point of the current application can be obtained by checking
Addenda: Package Manager Tips
The semantics of Node.js's function were designed to be general enough to support a number of reasonable directory structures.
Package manager programs such as and will hopefully find it possible to build native packages from Node.js modules without modification.
Below we give a suggested directory structure that could work:
Let's say that we wanted to have the folder at hold the contents of a specific version of a package
Packages can depend on one another.
In order to install package, it may be necessary to install a specific version of package
The package may itself have dependencies, and in some cases, these may even collide or form cyclic dependencies.
Since Node.js looks up the of any modules it loads (that is, resolves symlinks), and then looks for their dependencies in the
folders as described here, this situation is very simple to resolve with the following architecture:
Contents of the package, version 1.2.3.
Contents of the package that depends on.
Symbolic link to
Symbolic links to the packages that depends on.
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.
When the code in the package does, it will get the version that is symlinked into
Furthermore, to make the module lookup process even more optimal, rather than putting packages directly in, we could put them in
Then Node.js will not bother looking for missing dependencies in or
In order to make modules available to the Node.js REPL, it might be useful to also add the folder to the environment variable.
Since the module lookups using folders are all relative, and based on the real path of the files making the calls to the packages themselves can be anywhere.
All Together...
To get the exact filename that will be loaded when is called, use the function.
Putting together all of the above, here is the high-level algorithm in pseudocode of what does:
require(X) from module at path Y
If X is a core module,
return the core module
If X begins with
set Y to be the filesystem root
If X begins with or
"not found"
If X is a file, load X as JavaScript text.
parse to a JavaScript Object.
load as binary addon.
If is a file, Parse and look for "main" field.
let
for each in:
while
if
return
Caching
Modules are cached after the first time they are loaded.
This means (among other things) that every call to will get exactly the same object returned, if it would resolve to the same file.
Multiple calls to may not cause the module code to be executed multiple times. This is an important feature. With it, "partially done" objects can be returned, thus allowing transitive dependencies to be loaded even when they would cause cycles.
To have a module execute code multiple times, export a function, and call that function.
Module Caching Caveats
Modules are cached based on their resolved filename.
Since modules may resolve to a different filename based on the location of the calling module (loading from folders), it is not a guarantee that will always return the exact same object, if it would resolve to different files.
Additionally, on case-insensitive file systems or operating systems, different resolved filenames can point to the same file, but the cache will still treat them as different modules and will reload the file multiple times.
For example, and return two different objects, irrespective of whether or not and are the same file.
Core Modules
Node.js has several modules compiled into the binary. These modules are described in greater detail elsewhere in this documentation.
The core modules are defined within Node.js's source and are located in the folder.
Core modules are always preferentially loaded if their identifier is passed to
For instance, will always return the built in HTTP module, even if there is a file by that name.
Cycles
When there are circular calls, a module might not have finished executing when it is returned.
Consider this situation:
When loads, then in turn loads
At that point, tries to load
In order to prevent an infinite loop, an unfinished copy of the exports object is returned to the module.
then finishes loading, and its object is provided to the module.
By the time has loaded both modules, they're both finished.
The output of this program would thus be:
Careful planning is required to allow cyclic module dependencies to work correctly within an application.
File Modules
If the exact filename is not found, then Node.js will attempt to load the required filename with the added extensions: and finally
files are interpreted as JavaScript text files, and files are parsed as JSON text files.
files are interpreted as compiled addon modules loaded with
A required module prefixed with is an absolute path to the file.
For example, will load the file at
A required module prefixed with is relative to the file calling
That is, must be in the same directory as for to find it.
Without a leading or to indicate a file, the module must either be a core module or is loaded from a folder.
If the given path does not exist, will throw an with its property set to
Folders as Modules
It is convenient to organize programs and libraries into self-contained directories, and then provide a single entry point to that library.
There are three ways in which a folder may be passed to as an argument.
The first is to create a file in the root of the folder, which specifies a module.
An example file might look like this:
If this was in a folder at, then would attempt to load
This is the extent of Node.js's awareness of files.
If the file specified by the entry of is missing and can not be resolved, Node.js will report the entire module as missing with the default error:
If there is no file present in the directory, then Node.js will attempt to load an or file out of that directory.
For example, if there was no file in the above example, then would attempt to load: