Hot Module Replacement

If Hot Module Replacement has been enabled via the HotModuleReplacementPlugin, its interface will be exposed under the module.hot property. Typically, users will check to see if the interface is accessible, then begin working with it. As an example, here's how you might accept an updated module:

if (module.hot) {
  module.hot.accept('./library.js', function() {
    // Do something with the updated library module...

The following methods are supported...

Module API


Accept updates for the given dependencies and fire a callback to react to those updates.

  dependencies, // Either a string or an array of strings
  callback // Function to fire when the dependencies are updated

When using ESM import all imported symbols from dependencies are automatically updated. Note: The dependency string must match exactly with the from string in the import. In some cases callback can even be omitted. Using require() in the callback doesn't make sense here.

When using CommonJS you need to update dependencies manually by using require() in the callback. Omitting the callback doesn't make sense here.

accept (self)

Accept updates for itself.

  errorHandler // Function to handle errors when evaluating the new version

When this module or dependencies are updated, this module can be disposed and re-evaluated without informing parents. This makes sense if this module has no exports (or exports are updated in another way).

The errorHandler is fired when the evaluation of this module (or dependencies) has thrown an exception.


Reject updates for the given dependencies forcing the update to fail with a 'decline' code.

  dependencies // Either a string or an array of strings

Flag a dependency as not-update-able. This makes sense when changing exports of this dependency can be handled or handling is not implemented yet. Depending on your HMR management code an update to this dependencies (or unaccepted dependencies of it) usually causes a full-reload of the page.

decline (self)

Reject updates for itself.


Flag this module as not-update-able. This make sense when this module has inrevertable side-effects, or HMR handling is not implemented for this module yet. Depending on your HMR management code an update to this module (or unaccepted dependencies) usually causes a full-reload of the page.

dispose (or addDisposeHandler)

Add a handler which is executed when the current module code is replaced. This should be used to remove any persistent resource you have claimed or created. If you want to transfer state to the updated module, add it to given data parameter. This object will be available at module.hot.data after the update.

module.hot.dispose(data => {
  // Clean up and pass data to the updated module...


Remove the callback added via dispose or addDisposeHandler.


Management API


Retrieve the current status of the hot module replacement process.

module.hot.status(); // Will return one of the following strings...
Status Description
The process is waiting for a call to check (see below)
The process is checking for updates
The process is getting ready for the update (e.g. downloading the updated module)
The update is prepared and available
The process is calling the dispose handlers on the modules that will be replaced
The process is calling the accept handlers and re-executing self-accepted modules
An update was aborted, but the system is still in it's previous state
An update has thrown an exception and the system's state has been compromised


Test all loaded modules for updates and, if updates exist, apply them.

module.hot.check(autoApply).then(outdatedModules => {
  // outdated modules...
}).catch(error => {
  // catch errors

The autoApply parameter can either be a boolean or options to pass to the apply method when called.


Continue the update process (as long as module.hot.status() === 'ready').

module.hot.apply(options).then(outdatedModules => {
  // outdated modules...
}).catch(error => {
  // catch errors

The optional options object can include the following properties:

  • ignoreUnaccepted (boolean): Ignore changes made to unaccepted modules.
  • ignoreDeclined (boolean): Ignore changes made to declined modules.
  • ignoreErrored (boolean): Ignore errors throw in accept handlers, error handlers and while reevaluating module.
  • onDeclined (function(info)): Notifier for declined modules
  • onUnaccepted (function(info)): Notifier for unaccepted modules
  • onAccepted (function(info)): Notifier for accepted modules
  • onDisposed (function(info)): Notifier for disposed modules
  • onErrored (function(info)): Notifier for errors

The info parameter will be an object containing some of the following values:

  type: "self-declined" | "declined" |
        "unaccepted" | "accepted" |
        "disposed" | "accept-errored" |
        "self-accept-errored" | "self-accept-error-handler-errored",
  moduleId: 4, // The module in question.
  dependencyId: 3, // For errors: the module id owning the accept handler.
  chain: [1, 2, 3, 4], // For declined/accepted/unaccepted: the chain from where the update was propagated.
  parentId: 5, // For declined: the module id of the declining parent
  outdatedModules: [1, 2, 3, 4], // For accepted: the modules that are outdated and will be disposed
  outdatedDependencies: { // For accepted: The location of accept handlers that will handle the update
    5: [4]
  error: new Error(...), // For errors: the thrown error
  originalError: new Error(...) // For self-accept-error-handler-errored:
                                // the error thrown by the module before the error handler tried to handle it.


Register a function to listen for changes in status.

module.hot.addStatusHandler(status => {
  // React to the current status...


Remove a registered status handler.


Further Reading

© JS Foundation and other contributors
Licensed under the Creative Commons Attribution License 4.0.