blog：JavaScript Module Systems Showdown: CommonJS vs AMD vs ES2015
官网链接：Hot Module Replacement（概念）
官网链接：Hot Module Replacement（API）
Modules
In modular programming, developers break programs up into discrete chunks of functionality called a module.
Each module has a smaller surface area than a full program, making verification, debugging, and testing trivial. Well-written modules provide solid abstractions and encapsulation boundaries, so that each module has a coherent design and a clear purpose within the overall application.
Node.js has supported modular programming almost since its inception. On the web, however, support for modules has been slow to arrive. Multiple tools exist that support modular JavaScript on the web, with a variety of benefits and limitations. webpack builds on lessons learned from these systems and applies the concept of modules to any file in your project.
What is a webpack Module
In contrast to Node.js modules, webpack modules can express their dependencies in a variety of ways. A few examples are:
- An ES2015
importstatement - A CommonJS
require()statement - An AMD
defineandrequirestatement - An
@importstatement inside of a css/sass/less file. - An image url in a stylesheet
url(...)or HTML<img src=...>file.
Supported Module Types
webpack supports modules written in a variety of languages and preprocessors, via loaders. Loadersdescribe to webpack how to process non-JavaScript modules and include these dependencies into your bundles. The webpack community has built loaders for a wide variety of popular languages and language processors, including:
And many others! Overall, webpack provides a powerful and rich API for customization that allows one to use webpack for any stack, while staying non-opinionated about your development, testing, and production workflows.
For a full list, see the list of loaders or write your own.
How It Works
Let's go through some different viewpoints to understand exactly how HMR works...
In the Application
The following steps allow modules to be swapped in and out of an application:
- The application asks the HMR runtime to check for updates.
- The runtime asynchronously downloads the updates and notifies the application.
- The application then asks the runtime to apply the updates.
- The runtime synchronously applies the updates.
You can set up HMR so that this process happens automatically, or you can choose to require user interaction for updates to occur.
In the Compiler
In addition to normal assets, the compiler needs to emit an "update" to allow updating from the previous version to the new version. The "update" consists of two parts:
- The updated manifest (JSON)
- One or more updated chunks (JavaScript)
The manifest contains the new compilation hash and a list of all updated chunks. Each of these chunks contains the new code for all updated modules (or a flag indicating that the module was removed).
The compiler ensures that module IDs and chunk IDs are consistent between these builds. It typically stores these IDs in memory (e.g. with webpack-dev-server), but it's also possible to store them in a JSON file.
n a Module
HMR is an opt-in feature that only affects modules containing HMR code. One example would be patching styling through the style-loader. In order for patching to work, the style-loader implements the HMR interface; when it receives an update through HMR, it replaces the old styles with the new ones.
Similarly, when implementing the HMR interface in a module, you can describe what should happen when the module is updated. However, in most cases, it's not mandatory to write HMR code in every module. If a module has no HMR handlers, the update bubbles up. This means that a single handler can update a complete module tree. If a single module from the tree is updated, the entire set of dependencies is reloaded.
See the HMR API page for details on the module.hot interface.
In the Runtime
Here things get a bit more technical... if you're not interested in the internals, feel free to jump to the HMR API page or HMR guide.
For the module system runtime, additional code is emitted to track module parents and children. On the management side, the runtime supports two methods: check and apply.
A check makes an HTTP request to the update manifest. If this request fails, there is no update available. If it succeeds, the list of updated chunks is compared to the list of currently loaded chunks. For each loaded chunk, the corresponding update chunk is downloaded. All module updates are stored in the runtime. When all update chunks have been downloaded and are ready to be applied, the runtime switches into the ready state.
The apply method flags all updated modules as invalid. For each invalid module, there needs to be an update handler in the module or in its parent(s). Otherwise, the invalid flag bubbles up and invalidates parent(s) as well. Each bubble continues until the app's entry point or a module with an update handler is reached (whichever comes first). If it bubbles up from an entry point, the process fails.
Afterwards, all invalid modules are disposed (via the dispose handler) and unloaded. The current hash is then updated and all accept handlers are called. The runtime switches back to the idle state and everything continues as normal.
Get Started
HMR can be used in development as a LiveReload replacement. webpack-dev-server supports a hot mode in which it tries to update with HMR before trying to reload the whole page. See the Hot Module Replacement guide for details.
As with many other features, webpack's power lies in its customizability. There are many ways of configuring HMR depending on the needs of a particular project. However, for most purposes,
webpack-dev-serveris a good fit and will allow you to get started with HMR quickly.
JavaScript Module Systems Showdown: CommonJS vs AMD vs ES2015
Learn about the different JavaScript module systems currently in use, and find out which will be the best option for your project.