Webpack Hot Server Middleware
Webpack Hot Server Middleware is designed to be used in conjunction with webpack-dev-middleware
(and optionally webpack-hot-middleware
) to hot update Webpack bundles on the server.
Why?
When creating universal Web apps it's common to build two bundles with Webpack, one client bundle targeting 'web' and another server bundle targeting 'node'.
The entry point to the client bundle renders to the DOM, e.g.
// client.js ;; ReactDOM;
And the entry point to the server bundle renders to string, e.g.
// server.js ;; { return { resstatus200; };}
NOTE: The server bundle is itself middleware allowing you to mount it anywhere in an existing node server, e.g.
const express = ;const serverRenderer = ;const app = ; app;app;
Given this setup it's fairly easy to hook up hot module replacement for your client bundle using webpack-dev-server
or webpack-hot-middleware
however these middlewares don't handle server bundles meaning you need to frequently restart your server to see the latest changes.
Webpack Hot Server Middleware solves this problem, ensuring the server bundle used is always the latest compilation without requiring a restart. Additionally it allows your client and server bundle to share the same Webpack cache for faster builds and uses an in-memory bundle on the server to avoid hitting the disk.
How?
It turns out hot module replacement is much easier on the server than on the client as you don't have any state to preserve because middleware is almost always necessarily stateless, so the entire bundle can be replaced at the top level whenever a change occurs.
Usage
Webpack Hot Server Middleware expects your Webpack config to export an array of configurations, one for your client bundle and one for your server bundle, e.g.
// webpack.config.js moduleexports = name: 'client' target: 'web' entry: './client.js' ... name: 'server' target: 'node' entry: './server.js' ... ;
NOTE: It's important both the 'client' and 'server' configs are given a name prefixed with 'client' and 'server' respectively.
It then needs to be mounted immediately after webpack-dev-middleware
, e.g.
const express = ;const webpack = ;const webpackDevMiddleware = ;const webpackHotServerMiddleware = ;const config = ;const app = ; const compiler = ; app;app; app;
Now whenever Webpack rebuilds, the new bundle will be used both client and server side.
API
webpackHotServerMiddleware (compiler: MultiCompiler, options?: Options) => void
Options
chunkName string
The name of the server entry point, defaults to 'main'.
serverRendererOptions object
Mixed in with clientStats
& serverStats
and passed to the serverRenderer
.
Example
A simple example can be found in the example directory and a more real world example can be seen in the 60fram.es boilerplate.
webpack-hot-middleware
Usage with webpack-hot-middleware
needs to be mounted before webpack-hot-server-middleware
to ensure client hot module replacement requests are handled correctly, e.g.
const express = ;const webpack = ;const webpackDevMiddleware = ;const webpackHotMiddleware = ;const webpackHotServerMiddleware = ;const config = ;const app = ; const compiler = ; app;// NOTE: Only the client bundle needs to be passed to `webpack-hot-middleware`.app;app; app;
Production Setup
A production setup might conditionally use express.static
instead of webpack-dev-server
and a pre-built server bundle instead of webpack-hot-server-middleware
, e.g.
const express = ;const path = ;const app = ; if processenvNODE_ENV !== 'production' const webpack = ; const webpackDevMiddleware = ; const webpackHotMiddleware = ; const webpackHotServerMiddleware = ; const config = ; const compiler = ; app; app; app; else const CLIENT_ASSETS_DIR = path; const CLIENT_STATS_PATH = path; const SERVER_RENDERER_PATH = path; const serverRenderer = ; const stats = ; app; app; app;
License
MIT