webpack 实现 HMR 及其实现原理

前言

在这以前我老是容易把热重载和模块热替换混淆成一个概念，在本身动手实现以后才发现二者仍是有一些差异的。

• 热加载能够经过开启webpack-dev-server来实现，每次修改代码都会刷新整个页面
• 模块热替换也称为HMR，代码更新时只会更新被修改部分都显示 HMR相比热加载的好处：
• 针对于样式调试更加方便
• 只会更新被修改代码的那部分显示，提高开发效率
• 保留在彻底从新加载页面时丢失的应用程序状态。

实现HMR

HMR的有两种实现方式，一种是经过插件HotModuleReplacementPlugin和devserver配和实现，一种是经过在自定义开发服务下，使用插件webpack-dev-middleware和webpack-Hot-middleware配合实现HMR

经过插件HotModuleReplacementPlugin()

1.配置 在webpack.config.js中配置devServer

devServer: {
		contentBase: './dist',  // 起一个在dist文件夹下的服务器
		open: true,  // 自动打开浏览器并访问服务器地址
		port: 8085,
                hot: true,      // 开启HMR功能
                 hotOnly: true   // 即便HMR不生效，也不自动刷新
	},
复制代码

pluginsp配置中使用HotModuleReplacementPlugin插件

plugins: [
   ...// 其余插件
    new webpack.HotModuleReplacementPlugin()
    ],
复制代码

2.判断 而后进行手动判断进行模块热更新，若是你不想作如下判断那么可使用module.hot.accept()，整个项目作hmr只要有代码变化就进行更新。

if(module.hot) {
    module.hot.accept('./number', () => {
      // 使用更新过的 library 模块执行某些操做...
    })
}
复制代码

3.启动 最重要一点不要忘了修改启动命令

"start": "webpack-dev-server"
复制代码

此时运行npm start,便可实现模块热更新

经过 Node.js API

经过本身在本地搭建一个服务器，利用webpack-dev-middleware和webpack-Hot-middleware两个插件来配合实现HMR. 1.安装

// 安装express, webpack-dev-middleware , webpack-Hot-middleware
cnpm install express webpack-dev-middleware webpack-Hot-middleware -D
复制代码

2.配置dev.server.js dev.server.js

const path = require('path');
const express = require('express');
const webpack = require('webpack');
const webpackDevMiddleware = require('webpack-dev-middleware');
const webpackHotMiddleware = require("webpack-Hot-middleware")
const config = require('./webpack.dev.js');

const complier = webpack(config);   // 编译器，编译器执行一次就会从新打包一下代码
const app = express();  // 生成一个实例
const {devServer: {port, contentBase}} = config
const DIST_DIR = path.resolve(__dirname, '../', contentBase);  // 设置静态访问文件路径
// 等同于const DIST_DIR = path.resolve(__dirname, '../dist');


let devMiddleware = webpackDevMiddleware(complier, {  // 使用编译器
    publicPath: config.output.publicPath,
    quiet: true, //向控制台显示任何内容
    noInfo: true
})

let hotMiddleware = webpackHotMiddleware(complier,{
    log: false,
    heartbeat: 2000
 })

app.use(devMiddleware)

app.use(hotMiddleware)

// 设置访问静态文件的路径
app.use(express.static(DIST_DIR))


app.listen(port, () => {
    console.log("成功启动：localhost:"+ port)
})  //监听端口
复制代码

webpack.dev.js配置

module.exports = {
        entry: {             // 入口文件配置
        //实现刷新浏览器webpack-hot-middleware/client?noInfo=true&reload=true 是必填的
        main: ['webpack-hot-middleware/client?noInfo=true&reload=true', './src/index.js']
    },
       devServer: {
        contentBase: 'dist',
        port: 8081
    },
       plugins: [  
        new webpack.NamedModulesPlugin(),  //用于启动HMR时能够显示模块的相对路径
        new webpack.HotModuleReplacementPlugin(), 
        new OpenBrowserPlugin({ url: 'http://localhost:8081' }), // 自动打开浏览器
    ],
    ...// 其余配置
}
复制代码

完整实如今这里

webpack-hot-middleware的配置项

配置项能够经过query 方式添加到webpack config中的路径来传递给客户端 配置项都有

• path - 中间件为事件流提供的路径
• name - 捆绑名称，专门用于多编译器模式
• timeout - 尝试从新链接后断开链接后等待的时间
• overlay - 设置为false禁用基于DOM的客户端覆盖。
• reload - 设置为true在Webpack卡住时自动从新加载页面。
• noInfo - 设置为true禁用信息控制台日志记录。
• quiet - 设置为true禁用全部控制台日志记录。
• dynamicPublicPath - 设置为true使用webpack publicPath做为前缀path。（咱们能够__webpack_public_path__在入口点的运行时动态设置，参见output.- publicPath的注释）
• autoConnect - 设置为false用于防止从客户端自动打开链接到Webpack后端 - 若是须要使用该setOptionsAndConnect功能修改选项

经过传递第二个参数，能够将配置选项传递给中间件

webpackHotMiddleware(webpack,{
    log: false,
    path: "/__what",
    heartbeat: 2000
})
复制代码

• log - 用于记录行的函数，传递false到禁用。默认为console.log
• path - 中间件将服务事件流的路径必须与客户端设置相匹配
• heartbeat - 多长时间将心跳更新发送到客户端以保持链接的活动。应小于客户的timeout设置 - 一般设置为其一半值。 更多配置在这里webpack-hot-middleware

注意：经过express启动服务器后，devServer中的配置就不起做用了。

3.启动命令

"start": "node ./build/dev-server.js",
复制代码

启动命令npm start，便可实现HMR的功能

HMR实现原理

1.HMR的更新流程

• 修改了一个或多个文件。
• 文件系统接收更改并通知Webpack。
• Webpack从新编译构建一个或多个模块，并通知HMR服务器进行了更新。
• HMR Server使用websockets通知HMR Runtime须要更新。（HMR运行时经过HTTP请求这些更新。）
• HMR运行时再替换更新中的模块。若是肯定这些模块没法更新，则触发整个页面刷新

2.HMR 工做流程图解 此为更加详细的流程分析：

上图是webpack 配合 webpack-dev-server 进行应用开发的模块热更新流程图。

• 上图底部红色框内是服务端，而上面的橙色框是浏览器端。
• 绿色的方框是 webpack 代码控制的区域。蓝色方框是 webpack-dev-server 代码控制的区域，洋红色的方框是文件系统，文件修改后的变化就发生在这，而青色的方框是应用自己 步骤分析：
• 第一步，在 webpack 的 watch 模式下，文件系统中某一个文件发生修改，webpack 监听到文件变化，根据配置文件对模块从新编译打包，并将打包后的代码经过简单的 JavaScript 对象保存在内存中。
• 第二步是 webpack-dev-server 和 webpack 之间的接口交互，而在这一步，主要是 dev-server 的中间件 webpack-dev-middleware 和 webpack 之间的交互，webpack-dev-middleware 调用 webpack 暴露的 API对代码变化进行监控，而且告诉 webpack，将代码打包到内存中。
• 第三步是 webpack-dev-server 对文件变化的一个监控，这一步不一样于第一步，并非监控代码变化从新打包。当咱们在配置文件中配置了devServer.watchContentBase 为 true 的时候，Server 会监听这些配置文件夹中静态文件的变化，变化后会通知浏览器端对应用进行 live reload。注意，这儿是浏览器刷新，和 HMR 是两个概念。
• 第四步也是 webpack-dev-server 代码的工做，该步骤主要是经过 sockjs（webpack-dev-server 的依赖）在浏览器端和服务端之间创建一个 websocket 长链接，将 webpack 编译打包的各个阶段的状态信息告知浏览器端，同时也包括第三步中 Server 监听静态文件变化的信息。浏览器端根据这些 socket 消息进行不一样的操做。固然服务端传递的最主要信息仍是新模块的 hash 值，后面的步骤根据这一 hash 值来进行模块热替换。
• webpack-dev-server/client 端并不可以请求更新的代码，也不会执行热更模块操做，而把这些工做又交回给了 webpack，webpack/hot/dev-server 的工做就是根据 webpack-dev-server/client 传给它的信息以及 dev-server 的配置决定是刷新浏览器呢仍是进行模块热更新。固然若是仅仅是刷新浏览器，也就没有后面那些步骤了。
• HotModuleReplacement.runtime 是客户端 HMR 的中枢，它接收到上一步传递给他的新模块的 hash 值，它经过 JsonpMainTemplate.runtime 向 server 端发送 Ajax 请求，服务端返回一个 json，该 json 包含了全部要更新的模块的 hash 值，获取到更新列表后，该模块再次经过 jsonp 请求，获取到最新的模块代码。这就是上图中 七、八、9 步骤。
• 而第 10 步是决定 HMR 成功与否的关键步骤，在该步骤中，HotModulePlugin 将会对新旧模块进行对比，决定是否更新模块，在决定更新模块后，检查模块之间的依赖关系，更新模块的同时更新模块间的依赖引用。
• 最后一步，当 HMR 失败后，回退到 live reload 操做，也就是进行浏览器刷新来获取最新打包代码。

参考连接

• 模块热替换
• Webpack HMR 原理解析