buy the book to support the author.
Chapter 31. Module Systems and Package Managers
JavaScript does not have built-in support for modules, but the community has created impressive workarounds. To manage modules, you can use so-called package managers, which handle discovery, installation, dependency management, and more.
Module Systems
The two most important (and unfortunately incompatible) standards for JavaScript modules are:
- CommonJS Modules (CJS)
- The dominant incarnation of this standard is Node.js modules (Node.js modules have a few features that go beyond CJS). Its characteristics include:
- Compact syntax
- Designed for synchronous loading
- Main use: server
- Asynchronous Module Definition (AMD)
- The most popular implementation of this standard is RequireJS. Its characteristics include:
- Slightly more complicated syntax, enabling AMD to work without
eval()
or a static compilation step - Designed for asynchronous loading
- Main use: browsers
Package Managers
When it comes to package managers, npm (Node Packaged Modules) is the canonical choice for Node.js. For browsers, two options are popular (among others):
- Bower is a package manager for the Web that supports both AMD and CJS.
- Browserify is a tool based on npm that compiles npm packages to something you can use in a browser.
Quick and Dirty Modules
For normal web development, you should use a module system such as RequireJS or Browserify. However, sometimes you just want to put together a quick hack. Then the following simple module pattern can help:
var
moduleName
=
function
()
{
function
privateFunction
()
{
...
}
function
publicFunction
(...)
{
privateFunction
();
otherModule
.
doSomething
();
// implicit import
}
return
{
// exports
publicFunction
:
publicFunction
};
}();
The preceding is a module that is stored in the global variable moduleName
. It does the following:
- Implicitly imports a dependency (the module
otherModule
) - Has a private function,
privateFunction
- Exports
publicFunction
To use the module on a web page, simply load its file and the files of its dependencies via <script>
tags:
<script
src=
"modules/otherModule.js"
></script>
<script
src=
"modules/moduleName.js"
></script>
<script
type=
"text/javascript"
>
moduleName
.
publicFunction
(...);
</script>
If no other module is accessed while a module is loaded (which is the case for moduleName
), then the order in which modules are loaded does not matter.
Here are my comments and recommendations:
- I’ve used this module pattern for a while, until I found out that I hadn’t invented it and that it had an official name. Christian Heilmann popularized it and called it the “revealing module pattern”.
- If you use this pattern, keep it simple. Feel free to pollute the global scope with module names, but do try to find unique names. It’s only for hacks, so there is no need to get fancy (nested namespaces, modules split across multiple files, etc.).