详解webpack-dev-server的配置属性

1.devServer.contentBase
 
它指定了服务器资源的根目录,若是不写入contentBase的值,那么contentBase默认是项目的目录。
在上面例子中产生错误和后来解决错误的缘由:
产生错误:由于bundle.js被 "放在了"咱们的项目根目录里,在dist/html里<script src="./bundle.js"></script>此时显然不能根据路径找到bundle.js
解决错误:经过配置contentBase: path.join(__dirname, "dist")将bundle.js "放在了"dist目录下,此时bundle.js和dist/index.html位于同一目录下,经过 src="./bundle.js"天然就找到bundle.js了
 
webpack打包和webpack-dev-server开启服务的区别——
webpack输出真实的文件,而webpack-dev-server输出的文件只存在于内存中,不输出真实的文件!(注意下面两张图的区别)
 
webpack:当咱们在终端运行"webpack"后:

 

webpack-dev-server:当咱们在终端运行"node_modules/.bin/webpack-dev-server后:
这也就是我在上面的阐述中将bundle.js"放在了"加上双引号的缘由
 
 
你要提供哪里的内容给虚拟服务器用。这里最好填 绝对路径。

// 单目录
contentBase: path.join(__dirname, "public")

// 多目录
contentBase: [path.join(__dirname, "public"), path.join(__dirname, "assets")]
默认状况下,它将使用您当前的工做目录来提供内容。

 

 
2.devServer.port
port配置属性指定了开启服务的端口号:
devServer: {
   port:7000
}
设置端口号为7000:
运行:node_modules/.bin/webpack-dev-server
这个时候就不是默认的8080的端口了,而是咱们设置的7000
 
3.devServer.host
host设置的是服务器的主机号:
修改配置为:
devServer: {
   contentBase: path.join(__dirname, "dist"),
   port:7000,
   host:'0.0.0.0'
}

 

此时localhost:7000和0.0.0.0:7000都能访问成功
 
4.devServer.historyApiFallback
在文档里面说的很清楚, 这个配置属性是用来应对返回404页面时定向到特定页面用的(the index.html page will likely have to be served in place of any 404 responses)
在dist目录下新增一个HTML页面:
/*剩下的都是很常规的HTML内容,故省略*/
<p>这里是404界面</p>
 
咱们把webpack.config.js修改以下:
复制代码
module.exports = {
/*这里省略entry和output,参照上面写的内容*/
devServer: {
contentBase: path.join(__dirname, "dist"),
historyApiFallback:{
   rewrites:[
      {from:/./,to:'/404.html'}
   ]
  }
 }
}
复制代码
 
打开页面,输入一个不存在的路由地址:
 
 
若是为 true ,页面出错不会弹出 404 页面。
若是为 {...} , 看看通常里面有什么。

rewrites
rewrites: [
    { from: /^\/subpage/, to: '/views/subpage.html' },
    {
      from: /^\/helloWorld\/.*$/,
      to: function() {
          return '/views/hello_world.html;
      }
    }
]
// 从代码能够看出 url 匹配正则,匹配成功就到某个页面。
// 并不建议将路由写在这,通常 historyApiFallback: true 就好了。
verbose:若是 true ,则激活日志记录。
disableDotRule: 禁止 url 带小数点 . 。

 

 
5.watchOptions (文档
  • 一组自定义的监听模式,用来监听文件是否被改动过。
watchOptions: { aggregateTimeout: 300, poll: 1000, ignored: /node_modules/ }
  1. aggregateTimeout:一旦第一个文件改变,在重建以前添加一个延迟。填以毫秒为单位的数字。
  2. ignored:观察许多文件系统会致使大量的CPU或内存使用量。能够排除一个巨大的文件夹。
  3. poll:填以毫秒为单位的数字。每隔(你设定的)多少时间查一下有没有文件改动过。不想启用也能够填false
 
 

6.proxy (文档)

  • 当您有一个单独的API后端开发服务器,而且想要在同一个域上发送API请求时,则代理这些 url 。看例子好理解。
proxy: {
    '/proxy': { target: 'http://your_api_server.com', changeOrigin: true, pathRewrite: { '^/proxy': '' } }
  1. 假设你主机名为 localhost:8080 , 请求 API 的 url 是 http://your_api_server.com/user/list
  2. '/proxy':若是点击某个按钮,触发请求 API 事件,这时请求 url 是http://localhost:8080/proxy/user/list
  3. changeOrigin:若是 true ,那么 http://localhost:8080/proxy/user/list 变为 http://your_api_server.com/proxy/user/list 。但还不是咱们要的 url 。
  4. pathRewrite:重写路径。匹配 /proxy ,而后变为'' ,那么 url 最终为 http://your_api_server.com/user/list 。
 
 

7.publicPath (文档

  • 配置了 publicPath后, url = '主机名' + 'publicPath配置的' +
    '原来的url.path'
    。这个其实与 output.publicPath 用法大同小异。
  • output.publicPath 是做用于 js, css, img 。而 devServer.publicPath 则做用于请求路径上的。
// devServer.publicPath publicPath: "/assets/" // 本来路径 --> 变换后的路径 http://localhost:8080/app.js --> http://localhost:8080/assets/app.js

 

 
 
8.devServer.overlay
 
  • 若是为 true ,在浏览器上全屏显示编译的errors或warnings。默认 false (关闭)
 
   
  • 若是你只想看 error ,不想看 warning
overlay:{
    errors:true,
    warnings:false
}

 

配置属性用来在编译出错的时候,在浏览器页面上显示错误,默认是false,可设置为true
首先咱们人为制造一个编译错误:在咱们还没有配置babel loader的项目里使用ES6写法:
在src/index.js里写入“const a”
在shell里提示编译错误:
 
但在浏览器里没有提示:
因此咱们把webpack.config.js修改成:
复制代码
module.exports = {
     /*这里省略entry和output,参照上面写的内容*/
   devServer: {
       contentBase: path.join(__dirname, "dist"),
       overlay: true
   }
}
复制代码
 
再从新运行node_modules/.bin/webpack-dev-server,浏览器上把错误显示出来了

 

9.devServer.stats(字符串)
 
这个配置属性用来控制编译的时候shell上的输出内容,咱们没有设置devServer.stats时候编译输出是这样子的:
(其中看起来有许多看似不重要的文件也被打印出来了)

 

stats: "errors-only"表示只打印错误:
咱们把配置改为:
devServer: {
   contentBase: path.join(__dirname, "dist"),
   stats: "errors-only"
}
 
由于只有错误才被打印,因此,大多数信息都略过了
除此以外还有"minimal","normal","verbose",这里很少加赘述
 
10.devServer.quiet
true,则终端输出的只有初始启动信息。 webpack 的警告和错误是不输出到终端的
当这个配置属性和devServer.stats属于同一类型的配置属性
当它被设置为true的时候,控制台只输出第一次编译的信息, 当你保存后再次编译的时候不会输出任何内容,包括错误和警告
来作个对比吧:
quiet:false(默认):
第一次编译:
第二次编译(当你保存的时候)

quiet:truecss

第一次编译同上
第二次编译什么都不输出
 
11.devServer.compress
这是一个布尔型的值,当它被设置为true的时候对全部的服务器资源采用gzip压缩
采用gzip压缩的优势和缺点:
优势:对JS,CSS资源的压缩率很高,能够极大得提升文件传输的速率,从而提高web性能
缺点:服务端要对文件进行压缩,而客户端要进行解压,增长了两边的负载
 
12.devServer.hot和devServer.inline
在这以前,首先要说一下的是webpack-dev-server的自动刷新和模块热替换机制
 

webpack-dev-server的自动刷新和模块热替换机制 ,这两个机制是牢牢联系在一块儿的html

 
从外部角度看——自动刷新
当咱们对业务代码作了一些修改而后保存后(command+s),页面会自动刷新,咱们所作的修改会直接同步到页面上,而不须要咱们刷新页面,或从新开启服务
(The webpack-dev-server supports multiple modes to automatically refresh the page)
 
从内部角度看——模块热替换
在热替换(HMR)机制里,不是重载整个页面,HMR程序会只加载被更新的那一部分模块,而后将其注入到运行中的APP中
(In Hot Module Replacement, the bundle is notified that a change happened. Rather than a full page reload, a Hot Module Replacement runtime could then load the updated modules and inject them into a running app.)
 
webpack-dev-server有两种模式能够实现自动刷新和模块热替换机制
1. Iframe mode (默认,无需配置)
页面被嵌入在一个iframe里面,而且在模块变化的时候重载页面
2.inline mode(需配置)添加到bundle.js中
当刷新页面的时候,一个小型的客户端被添加到webpack.config.js的入口文件中
例如在咱们的例子中,在使用inline mode的热替换后,至关于入口文件从
entry:{
    app:path.join(__dirname,'src','index.js')
}
变成了:
entry:{
    app:[path.join(__dirname,'src','index.js'),
             'webpack-dev-server/client?http://localhost:8080/'
          ]
}
从一个入口变成了两个入口,并实现刷新
 
那怎么才能inline mode模式的刷新呢?
 
你须要作这些:
1在配置中写入devServer.hot:true和devServer.inline:true
2增长一个插件配置webpack.HotModuleReplacementPlugin()
 
例如:
复制代码
var webpack = require('webpack')
module.exports = {
   /*省略entry ,output等内容*/
   plugins:[
        new webpack.HotModuleReplacementPlugin()
    ],
   devServer: {
        inline:true,
        hot:true
    }
}
复制代码
 
打开页面:
若是有上面两行输出则代表你已经配置成功
相关文章
相关标签/搜索