通过 webpack-dev-server 的这些配置,能够以多种方式改变其行为。这是一个基本的示例,利用 gzips 压缩 public/ 目录当中的所有内容并提供一个本地服务(serve):
output的publicPath
output
中的path
指定打包后的文件放在指定地址文件夹output
中还有一个publicPath
属性,该属性是指定index.html
文件打包引用的一个基本路径:- 它的默认值是一个空字符串,所以我们打包后引入
js
文件时,路径是bundle.js
;一般浏览器加载<script defer src="bundle.js"></script>
,默认会在前面加一个/
,于是src="/bundle.js"
,如果是本地打开html,是访问不到的,只能是启服务才能用 - 在开发中,因为会启动本地服务,所以我们可将其设置为
/
,路径是/bundle.js
,那么浏览器会根据所在的域名+路径去请求对应的资源;,当然了如果不设置publicPath,启动服务后,也是可以访问到资源的 - 如果我们希望在本地直接打开
html
文件来运行,会将其设置为./
,路径时./bundle.js
,可以根据相对路径去查找资源;
devServer的publicPath
- 这个是之后在
webpack serve
才会生效的 devServer
中也有一个publicPath
的属性,该属性是指定本地服务所在的文件夹:- 它的默认值是
/
,也就是我们直接访问端口即可访问其中的资源http://localhost:8080;
- 如果我们将其设置为了
/a/b/c
,那么我们需要通过http://localhost:8080/a/b/c
才能访问到对应的打包后的资源 - 并且这个时候,我们其中的
bundle.js
通过http://localhost:8080/bundle.js
也是无法访问的: - 所以必须将
output.publicPath
也设置为/abc
; - 官方其实有提到,建议
devServer.publicPath
与output.publicPath
相同; - 实际开发中,
publicPath
往往被设置为了\
devServer的contentBase
devServer
中contentBase
对于我们直接访问打包后的资源其实并没有太大的作用,它的主要作用是如果我们打包后的资源,又依赖于其他的一些资源,那么就需要指定从哪里来查找这个内容:- 比如在
index.html
中,有<script src="./www/test.js"></script>
- 但是这样打包后浏览器是无法通过相对路径去找到这个文件夹的
- 所以代码是这样的:
<script src="/abc.js"></script>
- 但是我们如何让它去查找到这个文件的存在呢? 设置
contentBase
即可 - 当然在
devServer
中还有一个可以监听contentBase
发生变化后重新编译的一个属性:watchContentBase
hotOnly、host配置
- hotOnly是当代码编译失败时,是否刷新整个页面:
- 默认情况下当代码编译失败修复后,我们会重新刷新整个页面;
- 如果不希望重新刷新整个页面,可以设置hotOnly为true;
- host设置主机地址:
- 默认值是localhost;
- 如果希望其他地方也可以访问,可以设置为 0.0.0.0;
- localhost 和 0.0.0.0 的区别:
- localhost:本质上是一个域名,通常情况下会被解析成127.0.0.1;
- 127.0.0.1:回环地址(Loop Back Address),表达的意思其实是我们主机自己发出去的包,直接被自己接收;
- 正常的数据库包经常 应用层 - 传输层 - 网络层 - 数据链路层 - 物理层 ;
- 而回环地址,是在网络层直接就被获取到了,是不会经常数据链路层和物理层的;
- 比如我们监听 127.0.0.1时,在同一个网段下的主机中,通过ip地址是不能访问的;
- 0.0.0.0:监听IPV4上所有的地址,再根据端口找到不同的应用程序;
- 比如我们监听 0.0.0.0时,在同一个网段下的主机中,通过ip地址是可以访问的;
port、open、compress
- port设置监听的端口,默认情况下是8080
- open是否打开浏览器:
- 默认值是false,设置为true会打开浏览器;
- 也可以设置为类似于 Google Chrome等值;
- compress是否为静态文件开启gzip compression:
- 默认值是false,可以设置为true;
Proxy代理
-
proxy是我们开发中非常常用的一个配置选项,它的目的设置代理来解决跨域访问的问题:
- 比如我们的一个api请求是 http://localhost:8888,但是本地启动服务器的域名是 http://localhost:8000,这个时候发送网络请求就会出现跨域的问题;
- 那么我们可以将请求先发送到一个代理服务器,代理服务器和API服务器没有跨域的问题,就可以解决我们的跨域问题了;
-
我们可以进行如下的设置:
- target:表示的是代理到的目标地址,比如 /api-hy/moment会被代理到http://localhost:8888/apihy/moment;
- pathRewrite:默认情况下,我们的 /api-hy 也会被写入到URL中,如果希望删除,可以使用pathRewrite;
- secure:默认情况下不接收转发到https的服务器上,如果希望支持,可以设置为false;
- changeOrigin:它表示是否更新代理后请求的headers中host地址;
changeOrigin的解析
- 这个 changeOrigin官方说的非常模糊,通过查看源码我发现其实是要修改代理请求中的headers中的host属性:
- 因为我们真实的请求,其实是需要通过 http://localhost:8888来请求的;
- 但是因为使用了代码,默认情况下它的值时 http://localhost:8000;
- 如果我们需要修改,那么可以将changeOrigin设置为true即可;
historyApiFallback
- historyApiFallback是开发中一个非常常见的属性,它主要的作用是解决SPA页面在路由跳转之后,进行页面刷新时,返回404的错误。
- boolean值:默认是false
- 如果设置为true,那么在刷新时,返回404错误时,会自动返回 index.html 的内容;
- object类型的值,可以配置rewrites属性:
- 可以配置from来匹配路径,决定要跳转到哪一个页面;
- 事实上devServer中实现historyApiFallback功能是通过connect-history-api-fallback库的:
- 可以查看connect-history-api-fallback 文档
resolve模块解析
- resolve用于设置模块如何被解析:
- 在开发中我们会有各种各样的模块依赖,这些模块可能来自于自己编写的代码,也可能来自第三方库;
- resolve可以帮助webpack从每个 require/import 语句中,找到需要引入到合适的模块代码;
- webpack 使用 enhanced-resolve 来解析文件路径;
- webpack能解析三种文件路径:
- 绝对路径(由于已经获得文件的绝对路径,因此不需要再做进一步解析。)
- 相对路径
- 在这种情况下,使用 import 或 require 的资源文件所处的目录,被认为是上下文目录;
- 在 import/require 中给定的相对路径,会拼接此上下文路径,来生成模块的绝对路径;
- 模块路径
- 在 resolve.modules中指定的所有目录检索模块;
- 默认值是 [‘node_modules’],所以默认会从node_modules中查找文件;
- 我们可以通过设置别名的方式来替换初识模块路径,具体后面讲解alias的配置;
确实文件还是文件夹
- 如果是一个文件:
- 如果文件具有扩展名,则直接打包文件;
- 否则,将使用 resolve.extensions选项作为文件扩展名解析;
- 如果是一个文件夹:
- 会在文件夹中根据 resolve.mainFiles配置选项中指定的文件顺序查找;
- resolve.mainFiles的默认值是 [‘index’];
- 再根据 resolve.extensions来解析扩展名;
extensions和alias配置
- extensions是解析到文件时自动添加扩展名:
- 默认值是 [‘.wasm’, ‘.mjs’, ‘.js’, ‘.json’];
- 所以如果我们代码中想要添加加载 .vue 或者 jsx 或者 ts 等文件时,我们必须自己写上扩展名;
- 另一个非常好用的功能是配置别名alias:
- 特别是当我们项目的目录结构比较深的时候,或者一个文件的路径可能需要 …/…/…/这种路径片段;
- 我们可以给某些常见的路径起一个别名;
如何区分开发环境
- 目前我们所有的webpack配置信息都是放到一个配置文件中的:webpack.config.js
- 当配置越来越多时,这个文件会变得越来越不容易维护;
- 并且某些配置是在开发环境需要使用的,某些配置是在生成环境需要使用的,当然某些配置是在开发和生成环境都会使用的;
- 所以,我们最好对配置进行划分,方便我们维护和管理;
- 那么,在启动时如何可以区分不同的配置呢?
- 方案一:编写两个不同的配置文件,开发和生成时,分别加载不同的配置文件即可;
- 方式二:使用相同的一个入口配置文件,通过设置参数来区分它们;
入口文件解析
- 我们之前编写入口文件的规则是这样的:./src/index.js,但是如果我们的配置文件所在的位置变成了 config 目录,我们是否应该变成 …/src/index.js呢?
- 如果我们这样编写,会发现是报错的,依然要写成 ./src/index.js;
- 这是因为入口文件其实是和另一个属性时有关的 context;
- context的作用是用于解析入口(entry point)和加载器(loader):
- 官方说法:默认是当前路径(但是经过我测试,默认应该是webpack的启动目录)
- 另外推荐在配置中传入一个值;
配置文件的分离
- 这里我们创建三个文件:
- webpack.comm.conf.js
- webpack.dev.conf.js
- webpack.prod.conf.js