webpack 开发体验问题

自动编译

• watch模式，监听文件变化，自动编译打包。命令行方式通过--watch

yarn webpack --watch

自动刷新浏览器，配合HotModuleReplacementPlugin插件

• browserSync为例：

browser-sync dist --files "*/"

• webpack-dev-server，官方推出的开发工具，提供开发服务器。集成自动编译和自动刷新浏览器等功能

1. 安装webpack-dev-server，为项目安装了webpack-dev-server-cli
2. 命令行启动

yarn webpack-dev-server // 自动使用webpack打包，并启动http server运行打包结果，还能监听文件变化，跟watch模式一样。

webpack为了提高打包效率，没有写到磁盘，而是写到了内存里。所以启动webpack-dev-server后是看不到打包的dist目录的，这样减少了磁盘操作，大大提高了构建效率

yarn webpack-dev-server --open // 自动打开浏览器

webpack dev server静态资源访问

• webpack dev server 只要是webpack打包输出的文件，都可以直接被访问。但是，如果有些其他静态也需要serve，就需要告知webpack dev server
• 具体方法是，在webpack.config.js里面新增配置

module.exports = {
    ......
   devServer: {
    contentBase: './public', // 指定额外的静态资源路径，可以是字符串或则数组
    hot: true,
    open: true,
    ......
    },
  },
  ......
  plugins: [
    ......
    // 开发阶段最好不要使用这个插件，因为使用了webpack-dev-server的话，通过contentBase指定了该开发文件夹里
    // 上线的时候再使用，防止频繁重复的打包时，每次都执行这个插件，这样开销就很大，构建效率就很低了
    // new CopyWebpackPlugin(['public'])
  ],
}

webpack dev server 代理API

devServer的proxy字段

proxy: {
      '/api': {
        // http://localhost:8080/api/users -> https://api.github.com/api/users
        target: 'https://api.github.com',
        // http://localhost:8080/api/users -> https://api.github.com/users
        pathRewrite: {
          '^/api': '',
        },
        // 不能使用 localhost:8080 作为请求 GitHub 的主机名
        // 因为默认是dev-server通过localhost:8080这个主机名去访问目标主机，设为true
        // 一般服务器那边一般通过主机名去判断这个请求属于哪个网站，然后把这个请求给到那个网站
        // 主机名是HTTP协议中的相关概念
        changeOrigin: true, // 这个字段说明看https://github.com/iuap-design/blog/issues/260
      },
    },

source map 源代码地图

• 维持转换后的代码和源代码之间的映射关系
• source map解决了源代码与运行代码不一致所产生的问题。

一般有三个文件，一个是混淆压缩后的代码.min.js，源文件.js，source map文件***.min.map(里面的sources数组，指向源文件)，min.js最后一行有下面这一行固定格式

//# sourceMappingURL=jquery-3.4.1.min.map

webpack 配置source map

• webpack 支持12种不同方式的source map

  
  
  屏幕快照 2021-06-29 23.30.41.png

• 每种方式的效率和效果各不相同
  那应该使用哪一种呢？

1. eval模式，eval是js函数，可以通过字符串运行js代码
   运行时，是另外开一个虚拟机的方式运行里面的js代码
   在eval后面添加 //# sourceURL=./foo/bar.js。那么它的运行环境就变成foo/bar.js。意味这可以通过sourceURL改变eval运行环境的名称，但其实它还是运行在虚拟机环境当中，只不过告诉了执行引擎这个执行代码的执行路径，这只是个标识。

   
   
   屏幕快照 2021-06-29 23.35.33.png

devtool: eval打包后，不会生产sourcemap文件，只是在每个模块的eval最后面添加 文件路径，告诉引擎，报错的是哪个文件。所以它的构建速度是最快的，但是效果是最差的，没有报错的行列信息。

屏幕快照 2021-06-29 23.42.28.png

webpack devtool模式对比

1、eval、eval-source-map（有行有列）、cheap-eval-source-map（只有行没有列，映射loader处理后的）、cheap-module-eval-source-map（只有行没有列，但是映射的是源码）

• eval -是否使用eval执行代码模块
• cheap - Source Map是否包含行信息
• module - 是否能够得到Loader处理之前的源代码
  2、inline -- source map：使用的是dataUrl的方式嵌入到代码当中，这种是最不可能用到的。
  3、hidden --source map，构建后的代码没有通过注释的方式引用source map。
  4、nosources 能看到错误的文件，但是没有源代码，只有行列信息，在开发者工具点击错误的时候，不会找到源代码，这样是保护我们的源代码。

webpack选择Source Map模式（建议）

1、开发环境下会选择：cheap-module-eval-source-map

• 我的代码每行不会超过80个字符，那这样定位到行就够了
• 我的代码经过Loader转换过后的差异较大，例如使用了Vue之类的框架
• 虽然这种模式打包启动的速度慢些，但是首次打包速度慢无所谓，项目使用webpack-dev-server以监视模式打包，而不是启动打包，重写打包相对较快。
  2、生产模式的打包：选择none，如果真的有必要可以使用nosources-source-map，只暴露源代码的位置，而不是暴露内容
• Source Map会暴露源代码，会被稍有技术的人，很容易泄露代码
• 调试是开发阶段的事情

webpack 自动刷新的问题，局部刷新不是reload