webpack之路径处理

通过 webpack-dev-server 的这些配置，能够以多种方式改变其行为。这是一个基本的示例，利用 gzips 压缩 public/ 目录当中的所有内容并提供一个本地服务(serve)：

output的publicPath

1. output中的path指定打包后的文件放在指定地址文件夹
2. output中还有一个publicPath属性，该属性是指定index.html文件打包引用的一个基本路径：
3. 它的默认值是一个空字符串，所以我们打包后引入js文件时，路径是 bundle.js；一般浏览器加载<script defer src="bundle.js"></script>，默认会在前面加一个/，于是src="/bundle.js"，如果是本地打开html，是访问不到的，只能是启服务才能用
4. 在开发中，因为会启动本地服务，所以我们可将其设置为 / ，路径是 /bundle.js，那么浏览器会根据所在的域名+路径去请求对应的资源；，当然了如果不设置publicPath，启动服务后，也是可以访问到资源的
5. 如果我们希望在本地直接打开html文件来运行，会将其设置为./，路径时 ./bundle.js，可以根据相对路径去查找资源；

devServer的publicPath

1. 这个是之后在webpack serve才会生效的
2. devServer中也有一个publicPath的属性，该属性是指定本地服务所在的文件夹：
3. 它的默认值是 /，也就是我们直接访问端口即可访问其中的资源 http://localhost:8080；
4. 如果我们将其设置为了 /a/b/c，那么我们需要通过 http://localhost:8080/a/b/c才能访问到对应的打包后的资源
5. 并且这个时候，我们其中的bundle.js通过 http://localhost:8080/bundle.js也是无法访问的：
6. 所以必须将output.publicPath也设置为 /abc；
7. 官方其实有提到，建议 devServer.publicPath 与 output.publicPath相同；
8. 实际开发中，publicPath往往被设置为了\

devServer的contentBase

1. devServer中contentBase对于我们直接访问打包后的资源其实并没有太大的作用，它的主要作用是如果我们打包后的资源，又依赖于其他的一些资源，那么就需要指定从哪里来查找这个内容：
2. 比如在index.html中，有<script src="./www/test.js"></script>
3. 但是这样打包后浏览器是无法通过相对路径去找到这个文件夹的
4. 所以代码是这样的：<script src="/abc.js"></script>
5. 但是我们如何让它去查找到这个文件的存在呢？ 设置contentBase即可
6. 当然在devServer中还有一个可以监听contentBase发生变化后重新编译的一个属性：watchContentBase

hotOnly、host配置

1. hotOnly是当代码编译失败时，是否刷新整个页面：
   1. 默认情况下当代码编译失败修复后，我们会重新刷新整个页面；
   2. 如果不希望重新刷新整个页面，可以设置hotOnly为true；
2. host设置主机地址：
   1. 默认值是localhost；
   2. 如果希望其他地方也可以访问，可以设置为 0.0.0.0；
3. localhost 和 0.0.0.0 的区别：
   1. localhost：本质上是一个域名，通常情况下会被解析成127.0.0.1;
   2. 127.0.0.1：回环地址(Loop Back Address)，表达的意思其实是我们主机自己发出去的包，直接被自己接收;
      1. 正常的数据库包经常 应用层 - 传输层 - 网络层 - 数据链路层 - 物理层 ;
      2. 而回环地址，是在网络层直接就被获取到了，是不会经常数据链路层和物理层的;
      3. 比如我们监听 127.0.0.1时，在同一个网段下的主机中，通过ip地址是不能访问的;
   3. 0.0.0.0：监听IPV4上所有的地址，再根据端口找到不同的应用程序;
      1. 比如我们监听 0.0.0.0时，在同一个网段下的主机中，通过ip地址是可以访问的;

port、open、compress

1. port设置监听的端口，默认情况下是8080
2. open是否打开浏览器：
   1. 默认值是false，设置为true会打开浏览器；
   2. 也可以设置为类似于 Google Chrome等值；
3. compress是否为静态文件开启gzip compression：
   1. 默认值是false，可以设置为true；
   2. 

Proxy代理

1. proxy是我们开发中非常常用的一个配置选项，它的目的设置代理来解决跨域访问的问题：

   1. 比如我们的一个api请求是 http://localhost:8888，但是本地启动服务器的域名是 http://localhost:8000，这个时候发送网络请求就会出现跨域的问题；
   2. 那么我们可以将请求先发送到一个代理服务器，代理服务器和API服务器没有跨域的问题，就可以解决我们的跨域问题了；

2. 我们可以进行如下的设置：

   1. target：表示的是代理到的目标地址，比如 /api-hy/moment会被代理到http://localhost:8888/apihy/moment；
   2. pathRewrite：默认情况下，我们的 /api-hy 也会被写入到URL中，如果希望删除，可以使用pathRewrite；
   3. secure：默认情况下不接收转发到https的服务器上，如果希望支持，可以设置为false；
   4. changeOrigin：它表示是否更新代理后请求的headers中host地址；

changeOrigin的解析

1. 这个 changeOrigin官方说的非常模糊，通过查看源码我发现其实是要修改代理请求中的headers中的host属性：
   1. 因为我们真实的请求，其实是需要通过 http://localhost:8888来请求的；
   2. 但是因为使用了代码，默认情况下它的值时 http://localhost:8000；
   3. 如果我们需要修改，那么可以将changeOrigin设置为true即可；

historyApiFallback

1. historyApiFallback是开发中一个非常常见的属性，它主要的作用是解决SPA页面在路由跳转之后，进行页面刷新时，返回404的错误。
2. boolean值：默认是false
3. 如果设置为true，那么在刷新时，返回404错误时，会自动返回 index.html 的内容；
4. object类型的值，可以配置rewrites属性：
5. 可以配置from来匹配路径，决定要跳转到哪一个页面；
6. 事实上devServer中实现historyApiFallback功能是通过connect-history-api-fallback库的：
7. 可以查看connect-history-api-fallback 文档

resolve模块解析

1. resolve用于设置模块如何被解析：
2. 在开发中我们会有各种各样的模块依赖，这些模块可能来自于自己编写的代码，也可能来自第三方库；
3. resolve可以帮助webpack从每个 require/import 语句中，找到需要引入到合适的模块代码；
4. webpack 使用 enhanced-resolve 来解析文件路径；
5. webpack能解析三种文件路径：
6. 绝对路径(由于已经获得文件的绝对路径，因此不需要再做进一步解析。)
7. 相对路径
8. 在这种情况下，使用 import 或 require 的资源文件所处的目录，被认为是上下文目录；
9. 在 import/require 中给定的相对路径，会拼接此上下文路径，来生成模块的绝对路径；
10. 模块路径
11. 在 resolve.modules中指定的所有目录检索模块；
12. 默认值是 [‘node_modules’]，所以默认会从node_modules中查找文件；
13. 我们可以通过设置别名的方式来替换初识模块路径，具体后面讲解alias的配置；

确实文件还是文件夹

1. 如果是一个文件：
2. 如果文件具有扩展名，则直接打包文件；
3. 否则，将使用 resolve.extensions选项作为文件扩展名解析；
4. 如果是一个文件夹：
5. 会在文件夹中根据 resolve.mainFiles配置选项中指定的文件顺序查找；
6. resolve.mainFiles的默认值是 [‘index’]；
7. 再根据 resolve.extensions来解析扩展名；

extensions和alias配置

1. extensions是解析到文件时自动添加扩展名：
2. 默认值是 [‘.wasm’, ‘.mjs’, ‘.js’, ‘.json’]；
3. 所以如果我们代码中想要添加加载 .vue 或者 jsx 或者 ts 等文件时，我们必须自己写上扩展名；
4. 另一个非常好用的功能是配置别名alias：
5. 特别是当我们项目的目录结构比较深的时候，或者一个文件的路径可能需要 …/…/…/这种路径片段；
6. 我们可以给某些常见的路径起一个别名；

如何区分开发环境

1. 目前我们所有的webpack配置信息都是放到一个配置文件中的：webpack.config.js
2. 当配置越来越多时，这个文件会变得越来越不容易维护；
3. 并且某些配置是在开发环境需要使用的，某些配置是在生成环境需要使用的，当然某些配置是在开发和生成环境都会使用的；
4. 所以，我们最好对配置进行划分，方便我们维护和管理；
5. 那么，在启动时如何可以区分不同的配置呢？
6. 方案一：编写两个不同的配置文件，开发和生成时，分别加载不同的配置文件即可；
7. 方式二：使用相同的一个入口配置文件，通过设置参数来区分它们；

入口文件解析

1. 我们之前编写入口文件的规则是这样的：./src/index.js，但是如果我们的配置文件所在的位置变成了 config 目录，我们是否应该变成 …/src/index.js呢？
2. 如果我们这样编写，会发现是报错的，依然要写成 ./src/index.js；
3. 这是因为入口文件其实是和另一个属性时有关的 context；
4. context的作用是用于解析入口（entry point）和加载器（loader）：
5. 官方说法：默认是当前路径（但是经过我测试，默认应该是webpack的启动目录）
6. 另外推荐在配置中传入一个值；

配置文件的分离

1. 这里我们创建三个文件：
2. webpack.comm.conf.js
3. webpack.dev.conf.js
4. webpack.prod.conf.js