Nest.js & Webpack Hot Module Replacement
By: Jt Earl
Tags: Typescript, Webpack, Nodejs, JavaScript, Expressjs

Hot Module Replacement, or HMR, can be found in many different languages and frameworks in software engineering to keep this article short the scope will be limited to HMR in webpack and, briefly, how it works with nest. For more information check out nestjs.com documentation on hot reload and webpack’s documentation on HMR

Nest.js

According to nestjs.com:

Nest is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with TypeScript (preserves compatibility with pure JavaScript) and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Reactive Programming). Under the hood, Nest makes use of Express, but also provides compatibility with a wide range of other libraries (e.g. Fastify). This allows for easy use of the myriad third-party plugins which are available.

Nest does most of its dirty work through annotations which gives it a feel similar to Java Spring. The most common use case for nest is quickly building a loosely coupled, scalable architecture using Typescript.

Webpack

Webpack is an open source JavaScript module bundler. At its most basic it bundles JavaScript files for use in a browser but can also be configured to minifiy, transform, or package anything.

What is Hot Module Replacement(HMR)?

HMR is a way to quickly replace modules in a running application, removing the need to reboot an entire server when changes are made. A high level view of HMR is that the run-time will occasionally download updates. The application will then sync by replacing the updated or removed modules.

Photo by Chiara Ferroni on Unsplash

A more in depth explanation is that the HMR run-time supports a check and apply method. When check is called an HTTP call goes out to update the JSON manifest. If this call fails, then HMR assumes there is no update. If the call succeeds, then the list of updated chunks are compared to the list of current chunks. For each current chunk the updated chunk is downloaded. When all chunks are downloaded the HMR run-time will then switch to ready. Now an apply method in your code, most likely in a router if using nest.js, will flag all updated modules as invalid and update handlers will stop bubbling up of the invalid designation. If there is no update handler for the code being updated, the invalid will continue to bubble up to the parent module until it reaches an update handler or an entry point and fails. Assuming the code has an update handler all invalid files will be discarded and the run-time will switch back to idle from ready.

What are some use cases for HMR?

The strongest use case I have found for HMR is in a development environment. Locally, without HMR my node server needed to be rebooted at every change and would take an average of 17 seconds to reboot. With HMR I was able to keep my node server up and running all day and updates were applied around 13 milliseconds. Nest.js also wraps its main.hmr.ts file in a conditional, so if HMR is disabled all HMR related code will be removed from the compiler. HMR also provides extremely fast styling changes comparable to if the changes were made in a browser debugger, and will retain application state during a reload.

Photo by Rishi Deep on Unsplash

How do I implement HMR?