【Webpack】devServer 实验报告

开发 前端
本文从开发过程中遇到的痛点出发,梳理了现代打包工具对我们日常开发的帮助和提效,并自娱自乐的结合表现和源码,照虎画猫完成了所谓的自洽模型。

 [[404559]]

Choosing a Development Tool

Webpack 的使用目前已经是前端开发工程师必备技能之一。若是想在本地环境启动一个开发服务快速开发我们的应用(而不是每次 coding 完,手动执行 run build,全量打包),大家只需在 Webpack 的配置中,增加 devServer 的配置即可。它的作用主要是用来伺服资源文件。webpack-dev-server(以下简称 wds) 已经为我们封装好了全面、丰富且可配置化的功能,配置工程师们只需通过 webpack.config 和 命令行参数 即可满足开发所需。 然而配置工程师们,发现 wds 的 hot、live reload 实际上相当于启用了一个 express 的 Http 服务器 + webpack-dev-middleware(以下简称 wdm) 等中间件。这个 Http 服务器 和 用户访问服务的 client 可以通过 websocket 通讯协议建立长连接,在 webpack 'watch' 到原始文件作出改动后,wds 会使用 webpack 的实时编译,再用 wdm 将 webpack 编译后文件会输出到内存中。每当应用程序请求一个文件时,wdm 匹配到了就把内存中缓存的对应结果以文件的格式返回给 client ,反之则进入到下一个中间件。 如果想要使用更多 wds 提供的配置功能,比如 proxy、static、open 等, 在 server 端增加中间件即可,这样配置工程师摇身一变,配置开发工程师! 项目中的 devServer 我们更多是使用 webpack + express + webpack-dev-middleware + webpack-hot-middleware 的组合来完成 HMR。在系列文章中,有更加具体详细的学习分享来介绍这些,这里收缩一下,我们只关注 webpack-dev-server。

wds 在宏观世界的部分特性

Use webpack with a development server that provides live reloading. This should be used for development only. It uses webpack-dev-middleware under the hood, which provides fast in-memory access to the webpack assets.

webpack 配合一个开发服务器,可以提供热重载功能。但只用于开发模式下。 wds 的底层,集成了 wdm,可以提供快速内存访问打包资源的功能。

以上是 wds 对自己的一个简短自我介绍,我们来搞清楚它这么概括的点:

1. webpack 配合一个开发服务器,可以提供热重载功能。

webpack 可以通过 watch mode 的方式启动,指示 webpack 'watch' 依赖图中所有文件的更改,并且自动打包。但是每次打包后的结果将会存储到本地硬盘中,而 IO 操作是非常耗资源时间的,无法满足本地开发调试需求。 wds 则可以提供一个开发服务器,并且提供 live reloading(实时重载)功能,在打包完成后通知客户端,刷新页面重新加载资源。

2. 快速内存访问打包资源

wdm 可以将 webpack 编译后的资源输出到内存中,当应用程序请求资源时,可以直接从内存中进行响应。 开发中,我们还会注意到,在编译期间,客户端的请求会被 delay 到最新的编译结果完成之后才会去响应。

  1. 「wdm」: wait until bundle finished: /myapp/ 

3. HMR 模块热替换

日常开发修改完代码后,你有没有傻乎乎地,手动刷新调试页面,来验证现在的 bug 还是不是之前的那个 bug? 其实 HMR 会在应用程序运行过程中,替换、添加或删除模块,而无需重新加载整个页面。 可以通过以下几种方式,来显著提速开发效率:

  • 保留在完全重新加载页面期间丢失的应用程序状态
  • 只更新变更内容,以节省宝贵的开发时间
  • 在源代码中对 CSS/JS 进行修改,会立刻在浏览器中进行更新,这几乎相当于在浏览器 devtools 直接更改样式

4. 服务启动后自动启动浏览器 - open

有时候服务启动后,会打开 localhost:8080,或者打开浏览器的多个页签

5. 提供 history api 降级方案 - historyApiFallback

前端项目中,借助 history api,可以做到改变视图而不向后端发出请求。如果你手动刷新一个路由中匹配不到的页面,同时你的项目中没有配置 404 页面兜底逻辑,那就真的 404 Not Found 了。 wds 配置中有一项配置 historyApiFallback,可以配置一个页面代替所有的 404 响应。

  1. 「wds」: 404s will fallback to /index.html 

6. 提供代理功能 - proxy

wds 的 proxy配置使用方法,可以详见 Webpack-dev-server 的 proxy 用法。

  • 如果你有一个单独的后台 API 服务,你可以通过代理,把前端项目域名下发起的 API 请求,代理到后台的域名。
  • 解决开发环境中的跨域问题
  • 通过代理你还可以定制返回的 html 页面,比如同一个项目中你想要提供 PC、H5 两端的产物,通过 UA 判断,返回不同的打包产物 index.html or index.mobile.html

7. 代码打包编译出现警告和错误时,会在在页面上显示错误信息 - overlay

控制代码打包编译时出现警告和错误时,是否在页面上显示错误信息

8. output.path、output.publicPath、devServer.publicPath、devServer.contentBase

  • output.path 打包输出产物的绝对路径
  • output.publicPath 它会为所有打包后的资源指定一个基础路径,多用于静态资源服务器或者 CDN 托管静态资源
  • devServer.publicPath 挂载到服务器中间件的可访问虚拟地址
  • devServer.contentBase 加载这个配置下(文件夹下)的静态资源到服务器
  • output.path 打包产物的绝对路径,没有什么疑问。对于 output.publicPath、devServer.publicPath,还是有点迷惑不解吧? 假如有一个域名 example.com,但是你们应用部署在 example.com/myapp/ 。没有指定 output.publicPath,默认为 '/',这时 index.html 引用其他模块的 url 会是 /bundle.xxxhashxxx.js,这时这个资源的 url 就变成了 example.com/bundle.xxxhashxxx.js,毫无疑问,这个资源会 404 Not Found。如果指定 output.publicPath: '/myapp/',那么 index.html 中资源的 url 就变成了 '/myapp/bundle.xxxhashxxx.js'。 同理 wds 中,指定 devServer.publicPath: '/myapp/',devServer 就会在 http://localhost:8080/myapp/ 下伺服资源访问。模拟生产环境下的运维配置。
  1. 「wds」: webpack output is served from /myapp/ 

contentBase 呢?它只作用于 wds,只有你想要伺服静态资源文件的时候使用。换句话说,wds 会加载这个文件夹下的静态资源到服务器,而不需要 bundle 这个文件夹。 假如,你的 app 中需要加载一些 mp4 文件,这些文件基本不会被改动,所以你不必把这些资源打包到 /dist 文件下,可以把这些文件维护在 /src、/dist 的同级目录下的 /static。然后设置 contentBase: path.join(__dirname, 'static'),然后就可以在代码中这样引用静态资源了。

  1. 「wds」: Content not from webpack is served from /Volumes/bomb/git/webpack-learning/webpack-demo/static 

9. more

构建满足这些特性的自洽模型

为了验证我们构建的自洽模型,能够自洽,我们需要一个参照物来进行修正。 我们使用 devServer 官方配置,来伺服资源文件。 为了不影响体验,自洽模型 和 参考物 的代码都维护在第四节的参考,有兴趣的可以自己 debugger 一下。

1. 模拟 http 服务器

首先我们使用 express 启动一个本地 server,让浏览器可以访问本地的静态资源。

  1. // wds.server.js 
  2. const app = express(); 
  3. const listeningApp = http.createServer(app); 
  4. listeningApp.listen('8888''127.0.0.1', (err) => { 
  5.   createSocketServer(); 
  6. }); 

这里创建 http 服务器,没有使用 app.listen('8888', callback),而是使用 http.createServer(app) 的原因有两点:

在创建 websocket server(代码片段中的 createSocketServer)时,需要复用 http 服务器实例 listeningApp,在下一小节会介绍 wss

express 只返回 http 服务器实例,而 devServer 是支持配置 https 的,所以可以直接用 https.createServer(app),更加方便

2. 模拟监听代码文件更新

wds 调用 webpack api 对文件系统进行 'watch',当文件发生改变后,webpack 会重新对文件进行编译打包,然后保存到内存中。 这一系列操作,主要有两点:1、watch 文件更改;2、内存响应。所幸,wdm 完成了这部分功能,我们在自洽模型中直接引用 wdm 。

  1. // wds.server.js 
  2. const webpack = require('webpack'); 
  3. const wdm = require('webpack-dev-middleware'); 
  4. const config = require('./webpack.config.js'); 
  5.  
  6. const compiler = webpack(config); // 将 webpack.config.js 配置文件作为基础配置 
  7. const app = express(); 
  8. app.use(wdm(compiler)) // 告知 express 使用 webpack-dev-middleware 

这里不难看出,wdm(compiler) 的执行结果返回的是一个中间件,它将 webpack 编译后的文件存储到内存中,然后在用户访问 express 服务时,将内存中对应的资源输出返回。 那么 wdm 内部是如何实现的呢? wdm 的源码并不多,其核心只有 /index.js,/lib/middleware。

  1. // webpack-dev-middleware/index.js 
  2. // 在 compiler 的 invalid、run、done、watchRun 这 4 个编译生命周期上,注册对应的处理方法。 
  3. // 通过 tapable 来调用插件功能,主要是 report 编译的状态信息以及执行 context.callbacks 回调函数 
  4. const context = createContext(compiler, options); 
  5. ... 
  6. // 以监控的方式启动 webpack,调用 compiler 的 watch 方法,之后 webpack 便会监听文件变更,一旦检测到文件变更,就会重新执行编译。 
  7. context.watching = compiler.watch(options.watchOptions, (err) => { ... }); 
  8. ... 
  9. // 使用 memory-fs,将 webpack 的编译内容,输出至内存中 
  10. setFs(context, compiler); 

  1. // webpack-dev-middleware/lib/middleware 
  2. // 核心逻辑是:针对 request 请求,根据各种条件判断,最终返回对应的文件 
  3. module.exports = function wrapper(context) { 
  4.   // 返回 express 中间件函数的包装函数 
  5.   return function middleware(req, res, next) { 
  6.     // 如果不是 SSR,直接 next,流转到下一个中间件 
  7.     // 如果是 SSR,调用 util/ready,根据 state 判断执行回调 fn,还是将 fn 存储到 callbacks 队列中 
  8.     // ready 也是“在编译期间,停止提供旧版的 bundle 并且将请求延迟到最新的编译结果完成之后”的实现 
  9.    function goNext() { ... } 
  10.     // 根据请求的 req.url 地址,在 compiler 的内存文件系统中查找对应的文件,若查找不到,则直接调用 goNext() 方法处理请求 
  11.     let filename = getFilenameFromUrl( ... ) 
  12.     if (filename === false) { 
  13.       return goNext(); 
  14.     } 
  15.     // 根据上文找到的 filename 路径获取到对应的文件内容,并构造 response 对象返回 
  16.     // 最后也是调用 ready 
  17.     return new Promise((resolve) => { 
  18.      handleRequest(context, filename, processRequest, req); 
  19.       function processRequest() { 
  20.        ... 
  21.       } 
  22.     }) 
  23.   } 

3. 模拟 server 端:server 端 通知 client 端 文件发生改变

使用 HMR 的过程中,通过 network 我们知道 client 端 是通过 websocket 和 server 端 进行通信的。client 端 和 server 端 之间建立一个 websocket 长连接,将 webpack 编译打包的各个阶段的状态信息告知 client 端。最关键的还是 wds 注册 compiler hooks(compile、done、watchRun 等),当进入 webpack compile 生命周期时调用 hooks 回调注册方法。 compilation done 时,server 端 传递的最主要的信息是 'stats.hash' 和 'ok',然后 client 端 根据 hash 进行模块热更新。

  1. // wds.server.js 
  2. let connect = null // 长连接实例 
  3. // 调用 webpack api 监听 compile 的 done 事件 
  4. // 注册 compiler hooks -- done 
  5. const { done } = compiler.hooks 
  6. done.tap('myappPligins', (stats) => { 
  7.   if (connect) { 
  8.     let _stats = stats.toJson({...}) 
  9.     // 将编译打包后的新模块 hash 值发送到 client 端 
  10.     connect.write(JSON.stringify({ 
  11.       "type""hash"
  12.       "data": _stats.hash 
  13.     })) 
  14.     // 通知 client 端编译完成,可以进行 reloadApp 操作 
  15.     connect.write(JSON.stringify({ 
  16.       "type""ok" 
  17.     })) 
  18.   } 
  19. }); 
  20. // 创建 websocket server(wss) 
  21. // 目前 webpack-dev-server@4.X 使用 sockjs 会出错,webpack-dev-server@3.X 使用 ws 会报错 
  22. function createSocketServer () { 
  23.   let socket = sockjs.createServer({ 
  24.     sockjs_url: './sockjs-client' 
  25.   }); 
  26.   // 复用 http 服务器实例 listeningApp 
  27.   socket.installHandlers(listeningApp, { 
  28.     prefix: '/sockjs-node'
  29.   }); 
  30.   socket.on('connection', (connection) => { 
  31.     connect = connection 
  32.     ... 
  33.   }); 

4. client 端接收 wss 消息并触发响应

我们在业务代码中并没有添加接收 wss 消息的代码,那 client 端 的逻辑怎么实现的呢? 其实 wds 修改了 webpack.config.js 的基础配置,它会往 chunk 中偷偷塞入两个文件 webpack-dev-server/lib/client/index.js 和 webpack/hot/dev-server。 我们在自洽模型中也这么操作,这样这两段代码就植入到 client 端了。

  1. // wds.server.js 
  2. config.entry.app = [require.resolve('webpack/hot/dev-server'), './wds.client.js', config.entry.app] 
  3. // HMR 作为一个 Webpack 内置的功能,可以通过 HotModuleReplacementPlugin 开启 
  4. config.plugins.push( 
  5.   new webpack.HotModuleReplacementPlugin() 

client 端 通过 websocket 接收 server 端 最新编辑后的模块 hash 值,这个值会被存起来(currentHash),在接收到 ok 后才会 reloadApp。 如果配置了 hot,开启 HMR,会把程序控制权交给 webpack 的客户端代码进行 HMR。如果没有开启,就直接调用 location.reload() 刷新页面。

  1. // wds.client.js 
  2. const SockJS = require('./sockjs-client'
  3. const socketUrl = 'http://127.0.0.1:8888/sockjs-node' 
  4. let currentHash = '' // 最新代码模块的 hash 值 
  5.  
  6. function reloadApp () { 
  7.   if (options.hot) { 
  8.     let hotEmitter = require('webpack/hot/emitter'); 
  9.     // webpackHotUpdate 是 webpack 在 webpack/hot/dev-server.js 定义的一个事件,事件回调是获取此次编译的最新代码 
  10.     hotEmitter.emit('webpackHotUpdate', currentHash); 
  11.   } else if (options.liveReload) { // 没有配置 hmr,就直接 live reload 刷新页面 
  12.     location.reload(); 
  13.   } 
  14. // 处理 wss 通知 
  15. const onSocketMessage = { 
  16.   ... 
  17.   hash: function hash(_hash) { 
  18.     currentHash = _hash; // wss 端 通知 client 端 最新编辑后的模块 hash 值,这个值会被存起来(currentHash),在接收到 ok 后才会 reloadApp 
  19.   }, 
  20.   ok: function ok() { 
  21.     reloadApp(); 
  22.   } 
  23. }; 
  24.  
  25. const socket = (url, handlers) => { 
  26.   client = new SockJS(url) 
  27.  ... 
  28.   client.onmessage = function (data) { // 接收 wss 通知 
  29.     var msg = JSON.parse(data.data); 
  30.     if (handlers[msg.type]) { 
  31.       handlers[msg.type](msg.data); 
  32.     } 
  33.   } 
  34.   ... 
  35. socket(socketUrl, onSocketMessage) 

5. 模拟 HMR or live reload当 client 端 收到 ok 的通知后,开启 hot 的 wds,会执行 reload 方法,然后调用 webpackHotUpdate

  1. // wds.client.js 
  2. let hotEmitter = require('webpack/hot/emitter'); 
  3. hotEmitter.emit('webpackHotUpdate', currentHash); 

然后程序被 client 端 的 webpack 接管(第四步中我们注入到 plugins 中的 webpack.HotModuleReplacementPlugin 就派上用场了),webpack 监听到 webpackHotUpdate 事件,并获取到最新的 hash 值,然后开始检查更新。

  1. // webpack/hot/dev-server.js 
  2. var hotEmitter = require("./emitter"); 
  3. hotEmitter.on("webpackHotUpdate"function (currentHash) { 
  4.   lastHash = currentHash; 
  5.   ... 
  6.   check(); 
  7. }); 
  8. // 检查更新 
  9. var check = function check() { 
  10.   module.hot.check(true
  11.     .then(updatedModules => { 
  12.       ... 
  13.     }) 

源码中,追踪到 module.hot.check,就不知道路该怎么走了,hot.check 是哪里来的? 系列文章中有单独介绍 HMR 的一章,这里我们就偷个懒,粗线条的勾勒一下大致过程。 hot.check 来自于 /webpack/lib/hmr/HotModuleReplacement.runtime.js。

利用上一次保存的hash值,调用 hotDownloadManifest 发送 xxx.hash.hot-update.json 的 ajax 请求

请求结果获取热更新模块相关信息,并进入热更新准备阶段。

  • c: chunkIds m: removedChunks r: removedModules

通过 JSONP 的方式,调用 loadUpdateChunk 在 document.head 添加 script 标签,发送 chunkId.hash.hot-update.js 请求。

下面就是拿到的 hot-update.js 的内容。

JSONP 返回的 js 文件立即执行,会调用 window.webpackHotUpdatewebpack_demo 方法。此方法会把更新的模块 moreModules (图中入参的第二个参数对象)赋值给全局全量 currentUpdate。

最后会调用 HMR runtime 的 hotApply 进行热更新模块替换

6. 模拟 history api 降级方案

  1. // wds.server.js 
  2. // 添加中间件 connect-history-api-fallback,解决 history api 降级 
  3. app.use(historyApiFallback({ 
  4.   htmlAcceptHeaders: ['text/html''application/xhtml+xml'], // 只对这些类型的请求进行 rewrite 
  5.   rewrites: [ 
  6.     { from: /./, to'/myapp/index.html' } 
  7.   ] 
  8. })) 

7. 模拟 proxy 代理

proxy 配置,我们经常使用,那 node 是如何代理请求的呢?

在 wds 中,借助创建的 http 服务器,其 proxy 功能的实现就是解析配置项,并挂载 http-proxy-middleware 中间件到 http 服务上。结合 proxy 的用法,wds/lib/Server.js 中的代码显得一目了然。 http-proxy-middleware 则借助于 node-http-proxy,用于将 node 服务端接收到的请求,转发到目标服务器,实现代理服务器的功能。 可以预见,整个流程的大致实现思路就是,通过配置项注册全局的请求转发规则,在中间件中拦截客户端的 request 请求匹配转发规则,然后调用 node-http-proxy 的 .web、.ws 方法进行转发请求。 http-proxy-middleware 将转发规则分为两大类进行配置,context 和 options。

  1. // Proxy middleware configuration. 
  2. var proxy = require('http-proxy-middleware'); 
  3.  
  4. var apiProxy = proxy('/api', { target: 'http://www.example.org' }); 
  5. //                   \____/   \_____________________________/ 
  6. //                     |                    | 
  7. //                   context             options 
  8.  
  9. // 'apiProxy' is now ready to be used as middleware in a server. 

context 用于匹配需要进行转发的客户端请求,默认值是 '/',客户端发起的所有请求都会被转发;也可以字符串 url、字符串 url 数组、通配符或者个性化方法,来决定哪些请求会被代理转发。http-proxy-middleware 使用 options 中

  • target 用于设置要转发到的目标服务器的 host;
  • pathRewrite: object/function,用于改写要转发到的目标服务器的 url path;
  • router: object/function,根据配置,将匹配的客户端请求,改写这次请求的 host。
  1. // rewrite path 
  2. pathRewrite: {'^/old/api' : '/new/api'
  3. // remove path 
  4. pathRewrite: {'^/remove/api' : ''
  5. // add base path 
  6. pathRewrite: {'^/' : '/basepath/'
  7. // custom rewriting 
  8. pathRewrite: function (path, req) {} 
  9.  
  10. router: { 
  11.     'integration.localhost:3000' : 'http://localhost:8001',  // host only 
  12.     'staging.localhost:3000'     : 'http://localhost:8002',  // host only 
  13.     'localhost:3000/api'         : 'http://localhost:8003',  // host + path 
  14.     '/rest'                      : 'http://localhost:8004'   // path only 

  1. // http-proxy-middleware/lib/index.js 
  2. function HttpProxyMiddleware(context, opts) { 
  3.  ... 
  4.   var config = configFactory.createConfig(context, opts) // 解析获取 context、options 
  5.   ... 
  6.   var proxy = httpProxy.createProxyServer({}) // 创建代理服务器,由这个服务器进行转发请求 
  7.   ... 
  8.   var pathRewriter = PathRewriter.create(proxyOptions.pathRewrite) // 将客户端请求路径转化为目标服务器的路径(pathname 部分),既可以是 key-value,也可以函数。 
  9.   ... 
  10.   function shouldProxy(context, req) { // 判断请求是否需要转发 
  11.     var path = req.originalUrl || req.url 
  12.     return contextMatcher.match(context, path, req) // 通过多种匹配方法校验客户端 req 是否需要转发 
  13.   } 
  14.   function prepareProxyRequest(req) { 
  15.     req.url = req.originalUrl || req.url 
  16.     var originalPath = req.url 
  17.     var newProxyOptions = _.assign({}, proxyOptions) 
  18.     __applyRouter(req, newProxyOptions) // 遍历 options.router,校验是否匹配客户端 req,匹配的话就改写这次请求的 host 
  19.     __applyPathRewrite(req, pathRewriter) // 如果有 pathRewriter,就匹配当前请求,匹配的话就将设置的目标服务器路径写入 req.url 
  20.     return newProxyOptions 
  21.   } 
  22.   ... 
  23.   function middleware(req, res, next) { // 真正的代理中间件 
  24.     if (shouldProxy(config.context, req)) { 
  25.       var activeProxyOptions = prepareProxyRequest(req) 
  26.       proxy.web(req, res, activeProxyOptions) // node-http-proxy 进行代理转发 
  27.     } else { 
  28.       next() 
  29.     } 
  30.   } 
  31.   ... 
  32.   return middleware 

这样看来,http-proxy-middleware 主要做的是解析转发规则、最终把代理转发的事情交给了 node-http-proxy,同时配置了相关的 Logger、绑定事件。

解析获取 context、options,并配置 Logger 实例

通过 node-http-proxy 创建代理服务器,并 attach proxy-events

根据 options.pathRewrite 生成路径转化器

匹配客户端请求,通过代理服务器转发 http, https, websocket 请求

自洽实是自娱自乐

本文从开发过程中遇到的痛点出发,梳理了现代打包工具对我们日常开发的帮助和提效,并自娱自乐的结合表现和源码,照虎画猫完成了所谓的自洽模型。其实自洽模型画的远不如猫,最多就是一个四支腿生物的简笔画了。权当梳理了一遍 wds 的工作流程,更加细节的东西,还需要大家一起动手才能挖掘出来,希望能对你的理解过程起到一定的帮助作用。

参考

参考一:社区文章

  1. webpack 官网
  2. publicPath、contentBase
  3. 十分钟搞懂 webpack
  4. 轻松理解 webpack 热更新原理
  5. 再不怕被问到 HMR
  6. wdm 源码解读
  7. Webpack-dev-server 的 proxy 用法
  8. 知乎 HMR 原理解析
  9. 关于 tapable 你需要知道这些
  10. 相关包的版本:

"webpack": "5.24.0", "webpack-cli": "4.5.0", "webpack-dev-server": "^3.11.2"

参考二:自洽模型的参照物

  1. // webpack.config.js 使用通用的 Vue 项目配置 
  2. module.exports = { 
  3.   mode: 'development'
  4.   entry: { 
  5.     app: './src/app.js' 
  6.   }, 
  7.   output: { 
  8.     filename: '[name].bundle.js'
  9.     path: path.resolve(__dirname, 'dist'), 
  10.     publicPath: '/myapp/' 
  11.   }, 
  12.   devtool: 'inline-source-map'
  13.   plugins: [ 
  14.   ...some plugins 
  15.   ], 
  16.   module: { 
  17.     rules: [ ...some loaders ] 
  18.   } 
  19. }; 

然后把 devServer 的配置单独维护在 webpack.dev.js

  1. // webpack.dev.js devServer 配置 
  2. module.exports = merge([ 
  3.   base, // webpack.config.js 
  4.   { 
  5.     mode: 'development'
  6.     devServer: { 
  7.       host: '127.0.0.1', // 服务器 host,默认为 localhost 
  8.       port: 7777, // 服务器端口号,默认为 8080 
  9.       opentrue, // string | boolean,启动后是否打开浏览器,当为字符串时,打开指定浏览器 
  10.       openPage: 'myapp/', // string | Array<string>, ['''index.html'], 'index.html', 打开浏览器后默认打开的页面,Array 打开多个页面 
  11.       compress: true
  12.       hot: true, // 是否启动热更新(HMR),热更新使用的是 webpack 中 HotModuleReplacementPlugin 
  13.       http2: false, // 是否设置 HTTP/2 服务器,为 true,则默认使用 https 作为服务 
  14.       // https: { 
  15.       //   key'',//fs.readFileSync('/path/to/server.key'), 
  16.       //   cert: '',//fs.readFileSync('/path/to/server.crt'), 
  17.       //   ca: '',//fs.readFileSync('/path/to/ca.pem'
  18.       // }, 
  19.       proxy: { 
  20.         '/api': { 
  21.           target: 'http://localhost:7777'
  22.           pathRewrite: { '^/api''' }, 
  23.           secure: false // HTTPS 设置为无效证书 
  24.         } 
  25.       }, 
  26.       // 静态文件属性 
  27.       publicPath: '/myapp/', // 挂载到服务器中间件的可访问虚拟地址 
  28.       contentBase: path.join(__dirname, 'static'), // devServer 伺服这个文件夹下的静态资源。换句话说会加载本地 /static 目录下的静态文件到服务器 
  29.       stats: 'minimal'
  30.       // 设置编译出错或警告后,页面是否会直接显示信息, boolean | {} 
  31.       // 默认为 false,当失败后会显示空白页 
  32.       // 设置为 true 后,编译失败会显示错误/警告的覆盖层,也可以设置为 object,显示多种类型信息 
  33.       overlay: { 
  34.         warnings: true
  35.         errors: true 
  36.       }, 
  37.       injectClient: true, // 是否要注入 WebSocket 客户端,将此属性设置为 false,那么 hot、overlay 等功能都会失效 
  38.       injectHot: true, // 是否注入 HMR, 这个属性是 injectClient 的子集。只影响热更新 
  39.       liveReload: false, // 是否开启自动刷新浏览器功能,优先级低于 hot 
  40.       // 是否将所有 404 页面都跳转到 index.html,当此属性设置为 true 或为 object 时并且使用 history API 时所有 404 页面会跳转到 index.html 或指定的页面 
  41.       historyApiFallback: { 
  42.         rewrites: [ 
  43.           { from: /./, to'/myapp/index.html' }, 
  44.         ] 
  45.       }, 
  46.       //  设置 WebSocket,设置使用的 WebSocket 库,内置为 sockjs 或 ws 
  47.       transportMode: { 
  48.         //  目前 webpack-dev-server@4.X 使用 sockjs 会出错,webpack-dev-server@3.X 使用 ws 会报错 
  49.         server: 'sockjs' 
  50.       } 
  51.     } 
  52.   } 
  53. ]) 

package.json

  1. // package.json 
  2. "scripts": { 
  3.   "start""webpack serve --config webpack.dev.js"
  4.    "start:dev""node wds.server.js"

参考三:自洽模型

  1. // wds.server.js 
  2. const express = require('express'); 
  3. const webpack = require('webpack'); 
  4. const http = require('http'); 
  5. const webpackDevMiddleware = require('webpack-dev-middleware'); 
  6. const historyApiFallback = require('connect-history-api-fallback'); 
  7. const sockjs = require('sockjs'); 
  8.  
  9. const app = express(); 
  10. const config = require('./webpack.config.js'); 
  11.  
  12. config.entry.app = [require.resolve('webpack/hot/dev-server'), './wds.client.js', config.entry.app] 
  13. config.plugins.push( 
  14.   new webpack.HotModuleReplacementPlugin() 
  15.  
  16. // 告知 express 使用 webpack-dev-middleware, 
  17. // 以及将 webpack.config.js 配置文件作为基础配置。 
  18. const compiler = webpack(config) 
  19.  
  20. // historyApiFallback 
  21. app.use(historyApiFallback({ 
  22.   htmlAcceptHeaders: ['text/html''application/xhtml+xml'], 
  23.   rewrites: [ 
  24.     { from: /./, to'/myapp/index.html' } 
  25.   ] 
  26. })) 
  27.  
  28. app.use( 
  29.   webpackDevMiddleware(compiler, { 
  30.     publicPath: config.output.publicPath, 
  31.   }) 
  32.  
  33. let connect = null 
  34.  
  35. const { done } = compiler.hooks 
  36. done.tap('myappPligins', (stats) => { 
  37.   if (connect) { 
  38.     let _stats = stats.toJson({ 
  39.       allfalse
  40.       hash: true
  41.       assets: true
  42.       warnings: true
  43.       errors: true
  44.       errorDetails: false
  45.     }) 
  46.     connect.write(JSON.stringify({ 
  47.       "type""hash"
  48.       "data": _stats.hash 
  49.     })) 
  50.     connect.write(JSON.stringify({ 
  51.       "type""ok" 
  52.     })) 
  53.   } 
  54. }); 
  55.  
  56.  
  57. const listeningApp = http.createServer(app); 
  58.  
  59. function createSocketServer () { 
  60.   let socket = sockjs.createServer({ 
  61.     sockjs_url: './sockjs-client' 
  62.   }); 
  63.   socket.installHandlers(listeningApp, { 
  64.     prefix: '/sockjs-node'
  65.   }); 
  66.   socket.on('connection', (connection) => { 
  67.     if (!connection) { 
  68.       return
  69.     } 
  70.  
  71.     connect = connection 
  72.  
  73.     // 通知 client enable 了哪些功能 
  74.     connection.write(JSON.stringify({ 
  75.       "type""hot" 
  76.     })) 
  77.   }); 
  78.  
  79. listeningApp.listen('8888''127.0.0.1', (err) => { 
  80.   console.log('Example app listening on port 8888!\n'); 
  81.   createSocketServer(); 
  82. }); 
  83.  
  84. listeningApp.on('error', (err) => { 
  85.   console.error(err); 
  86. }); 

  1. // wds.client.js 
  2. console.log('this is from client.'
  3. const SockJS = require('./sockjs-client'
  4. const socketUrl = 'http://127.0.0.1:8888/sockjs-node' 
  5. const options = { 
  6.   hot: true
  7.   hotReload: true
  8.   liveReload: false
  9.   initial: true
  10.   useWarningOverlay: false
  11.   useErrorOverlay: false
  12.   useProgress: false 
  13. let currentHash = '' 
  14.  
  15. function reloadApp () { 
  16.   if (options.hot) { 
  17.     console.log('[WDS] App hot update...'); 
  18.     let hotEmitter = require('webpack/hot/emitter'); 
  19.     hotEmitter.emit('webpackHotUpdate', currentHash); 
  20.     // broadcast update to window 
  21.     window.postMessage("webpackHotUpdate".concat(currentHash), '*'); 
  22.   } else if (options.liveReload) { 
  23.     location.reload(); 
  24.   } 
  25.  
  26. const onSocketMessage = { 
  27.   hot: function hot() { 
  28.     options.hot = true
  29.     console.info('[WDS] Hot Module Replacement enabled.'
  30.   }, 
  31.   liveReload: function liveReload() { 
  32.     options.liveReload = true
  33.     console.info('[WDS] Live Reloading enabled.'
  34.   }, 
  35.   invalid: function invalid() { 
  36.     console.info('[WDS] App updated. Recompiling...'
  37.   }, 
  38.   hash: function hash(_hash) { 
  39.     currentHash = _hash; 
  40.   }, 
  41.   ok: function ok() { 
  42.     reloadApp(); 
  43.   }, 
  44.   closefunction close() { 
  45.     console.error('[WDS] Disconnected!'); 
  46.   } 
  47. }; 
  48.  
  49. let retries = 0 
  50. let client = null 
  51.  
  52. const socket = (url, handlers) => { 
  53.   client = new SockJS(url) 
  54.   client.onopen = function () { 
  55.     retries = 0 
  56.   } 
  57.  
  58.   client.onmessage = function (data) { 
  59.     var msg = JSON.parse(data.data); 
  60.  
  61.     if (handlers[msg.type]) { 
  62.       handlers[msg.type](msg.data); 
  63.     } 
  64.   } 
  65.  
  66.   client.onclose = function () { 
  67.     if (retries === 0) { 
  68.       handlers.close(); 
  69.     } // Try to reconnect. 
  70.  
  71.     client = null; // After 10 retries stop trying, to prevent logspam. 
  72.  
  73.     if (retries <= 10) { 
  74.       var retryInMs = 1000 * Math.pow(2, retries) + Math.random() * 100; 
  75.       retries += 1; 
  76.       setTimeout(function () { 
  77.         socket(url, handlers); 
  78.       }, retryInMs); 
  79.     } 
  80.   } 
  81.  
  82. socket(socketUrl, onSocketMessage) 

 【编辑推荐】

 

责任编辑:姜华 来源: 微医大前端技术
相关推荐

2021-12-21 14:00:25

WebpackDevServer的开发

2011-05-25 17:51:40

2011-04-12 11:01:48

LinuxUnix桌面

2022-03-08 09:16:20

webpack前端开发

2020-08-05 08:21:41

Webpack

2022-10-09 08:43:47

H5Webpack代码

2010-07-28 20:47:31

2012-11-08 20:22:18

2020-11-17 08:09:01

webpack配置项脚手架

2020-09-19 21:26:56

webpack

2011-04-22 10:30:11

VMwareWindowsFTP

2021-12-15 23:42:56

Webpack原理实践

2018-02-01 17:03:50

2021-12-16 22:02:28

webpack原理模块化

2017-03-24 10:56:21

Webpack技巧建议

2017-07-11 15:50:11

前端webpack2优化

2021-09-06 06:45:06

WebpackMindMasterEntry

2017-03-22 09:21:13

2009-05-04 13:53:41

2021-12-20 00:03:38

Webpack运行机制
点赞
收藏

51CTO技术栈公众号