webpack打包

✍目录总览：

问题的产生

浏览器环境中模块化开发的问题：

• 效率问题：模块化导致JS代码需要不断的被细分, 而精细的模块划分带来了更多的JS文件, 更多的JS文件带来了更多的网络请求, 降低了页面访问效率
• 兼容性问题：
  1. 浏览器不识别ES6（或者更高版本的JS语法）语法，或者CSS预编译处理器（如less，scss）
  2. 目前浏览器仅支持ES6的模块化, 那么意味着我们不能在代码中书写commonjs规范的代码, 更意味着我们在浏览器更加不能用commonjs导出的库和包, 我们知道, 学习了npm, yarn这类包管理工具以后, 我们不会再用很low的方式去引入库或者包, 都会用npm install的方式。
• 使用工具的兼容问题：在默认情况下, 浏览器跟npm的结合问题非常大, 要解决这个问题, 必须使用第三方工具。
• 代码环境问题：浏览器端, 开发环境（development）和线上环境（production）的侧重点完全不同：
  • 开发环境
    1. 模块划分越细越好
    2. 最好支持多种模块化标准
    3. 支持npm和其他包管理器下载的模块
    4. 能解决其他工程化的问题
  • 线上环境（代码上线后）
    1. 文件数量越少越好
    2. 文件体积越小越好
    3. 代码内容越乱越好
    4. 所有浏览器都要兼容
    5. 执行效率越高越好

问题的解决

什么是构建工具？

• 能够让开发者专心的书写开发环境的代码, 然后利用这个工具将开发时态编写的代码转化为运行时态的工具。

• 常见的构建工具：webpack、grunt、gulp、browserfly等等。

• 其中webpack是目前生态最繁荣构建工具。

• 所有资源文件(js/json/css/img/less/…)都会被webpack作为模块处理。

一、webpack概述

• webpack 是一个流行的前端项目构建工具（打包工具），可以解决当前 web 开发中所面临的困境。
• webpack 提供了友好的模块化支持，以及代码压缩混淆、处理 js 兼容问题、性能优化等强大的功能，从而让程序员把工作的重心放到具体的功能实现上，提高了开发效率和项目的可维护性。

• 五个核心概念：入口(Entry)、输出(Output)、Loader（加载器）、Plugins（插件）、Mode（模式）

  
  
  

二、webpack 的基本使用

2.1 在项目中安装和配置 webpack

① 运行 npm install webpack webpack-cli –D 命令，安装 webpack 相关的包

② 在项目根目录中，创建名为 webpack.config.js 的 webpack 配置文件

③ 在 webpack 的配置文件中，初始化如下基本配置：

④ 在 package.json 配置文件中的 scripts 节点下，新增 dev 脚本如下：

⑤ 在终端中运行 npm run dev 命令，启动 webpack 进行项目打包。

2.2 配置打包的入口与出口

webpack 的 4.x 版本中默认约定：

• 打包的入口文件为 src -> index.js
• 打包的输出文件为 dist -> main.js

如果要修改打包的入口与出口，可以在 webpack.config.js 中新增如下配置信息：

2.3 配置 webpack 的自动打包功能

① 运行 npm install webpack-dev-server –D 命令，安装支持项目自动打包的工具

② 修改 package.json -> scripts 中的 dev 命令如下：

③ 将 src -> index.html 中，script 脚本的引用路径，修改为 "/buldle.js“

④ 运行 npm run dev 命令，重新进行打包

⑤ 在浏览器中访问 http://localhost:8080 地址，查看自动打包效果

注意：

• webpack-dev-server 会启动一个实时打包的 http 服务器
• webpack-dev-server 打包生成的输出文件，默认放到了项目根目录中，而且是虚拟的、看不见的

2.4 配置 html-webpack-plugin 生成预览页面

① 运行 npm install html-webpack-plugin –D 命令，安装生成预览页面的插件

② 修改 webpack.config.js 文件头部区域，添加如下配置信息：

③ 修改 webpack.config.js 文件中向外暴露的配置对象，新增如下配置节点：

2.5 配置自动打包相关的参数

三、 webpack 中的加载器（loader）

1. 通过 loader 打包非 js 模块

在实际开发过程中，webpack 默认只能打包处理以 .js 后缀名结尾的模块，其他非 .js 后缀名结尾的模块，webpack 默认处理不了，需要调用 loader 加载器才可以正常打包，否则会报错！

loader 加载器可以协助 webpack 打包处理特定的文件模块，比如：

• less-loader 可以打包处理 .less 相关的文件
• sass-loader 可以打包处理 .scss 相关的文件
• url-loader 可以打包处理 css 中与 url 路径相关的文件

2. loader 的调用过程

四、webpack 中加载器的基本使用

1. 打包处理 css 文件

① 运行 npm i style-loader css-loader -D 命令，安装处理 css 文件的

② 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

其中，test 表示匹配的文件类型， use 表示对应要调用的 loader

注意：

• use 数组中指定的 loader 顺序是固定的
• 多个 loader 的调用顺序是：从后往前调用

2. 打包处理 less 文件

① 运行 npm i less-loader less -D 命令

② 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

3. 打包处理 scss 文件

① 运行 npm i sass-loader node-sass -D 命令

② 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

4. 配置 postCSS 自动添加 css 的兼容前缀

① 运行 npm i postcss-loader autoprefixer -D 命令

② 在项目根目录中创建 postcss 的配置文件 postcss.config.js，并初始化如下配置：

③ 在 webpack.config.js 的 module -> rules 数组中，修改 css 的 loader 规则如下：

5. 打包样式表中的图片和字体文件

① 运行 npm i url-loader file-loader -D 命令

② 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

其中 ? 之后的是 loader 的参数项。

limit 用来指定图片的大小，单位是字节(byte),只有小于 limit 大小的图片，才会被转为 base64 图片

6. 打包处理 js 文件中的高级语法（babel）

① 安装babel转换器相关的包：npm i babel-loader @babel/core @babel/runtime -D

② 安装babel语法插件相关的包：

③ 在项目根目录中，创建 babel 配置文件 babel.config.js 并初始化基本配置如下：

④ 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

五、打包发布

项目开发完成之后 ，需要使用 webpack 对项目进行打包发布 ，主要原因有以下两点：

1. 开发环境下，打包生成的文件存放于内存中 ，无法获取到最终打包生成的文件
2. 开发环境下，打包生成的文件 不会进行代码压缩和性能优化

为了让项目能够在生产环境中高性能的运行，因此需要对项目进行打包发布。

5.1、配置webpack的打包发布

在 package.json 文件的 scripts 节点下，新增 build 命令如下

-- model 是一个参数项，用来指定 webpack 的运行模式 。production 代表生产环境，会对打包生成的文件
进行代码压缩和性能优化 。

注意：通过 -- model 指定的参数项，会覆盖 webpack.config.js 中的 model 选项

5.2、把JavaScript文件统一生成到js目录中

在 webpack.config.js 配置文件的 output 节点中，进行如下的配置

5.3、把图片文件统一生成到 image 目录中

修改 webpack.config.js 中的 url-loader 配置项，新增 outputPath 选项即可指定图片文件的输出路径

5.4、自动清理 dist 目录下的旧文件

为了在每次打包发布时自动清理掉 dist 目录中的旧文件 ，可以安装并配置 clean-webpack-plugin 插件

1. 安装插件

2. 按需导入插件，得到插件的构造函数后，创建插件的实例对象

3. 把创建的 cleanPlugin 插件实例对象挂载到 plugins 节点中

六、Source Map

6.1、生产环境遇到的问题

前端项目在投入生产环境之前，都需要对JavaScript 源代码进行 压缩混淆 ，从而减小文件的体积，提高文件的加载效率。此时就不可避免的产生了另一个问题：

• 对压缩混淆之后的代码除错（debug）是一件极其困难的事情
• 变量被替换成 没有任何语义 的名称
• 空行和注释被剔除

6.2、什么是SourceMap

• Source Map就是一个信息文件，里面储存着位置信息
• 也就是说， Source Map 文件中存储着压缩混淆后的代码所对应的转换前的位置 。
• 有了它，出错的时候，除错工具将直接显示原始代码 ，而不是转换后的代码 ，能够极大的方便后期的调试。

6.2.1、webpack 开发环境下的 Source Map

在开发环境下，webpack 默认启用了 Source Map 功能。当程序运行出错时，可以直接在控制台提示错误行的位置，并定位到具体的源代码。

6.2.2、默认Source Map的问题

开发环境下默认生成的 SourceMap ，记录的是 生成后的代码的位置 。会导致运行时报错的行数与源代码的行数不一致的问题。示意图如下：

6.2.3、解决默认Source Map的问题

开发环境下，推荐在 webpack.config.js 中添加如下的配置，即可保证运行时报错的行数与源代码的行数保持一致

6.3、webpack生产环境下的SourceMap

在生产环境下 ，如果省略了 devtool 选项 ，则最终生成的文件中不包含 Source Map 。这能够防止原始代码通过Source Map 的形式暴露给别有所图之人。

6.3.1、只定位行数不暴露源码

在生产环境下，如果 只想定位报错的具体行数 ，且不想暴露源码 。此时可以将 devtool 的值设置为nosources-source-map 。实际效果如图所示：

6.3.2、定位行数且暴露源码

在生产环境下，如果想在定位报错行数的同时，展示具体报错的源码。此时可以将 devtool 的值设置为 source-map。实际效果如图所示：

6.4、Source Map最佳实践

• 开发环境下
  1. 建议把 devtool 的值设置为 eval-source-map
  2. 好处：可以精准定位到具体的错误行
• 生产环境下
  1. 建议关闭 Source Map 或将 devtool 的值设置为 nosources-source-map
  2. 好处：放置源码泄露，提高网站的安全性

总结：实际开发中不需要自己配置webpack

• 实际开发中会使命令行工具（俗称 CLI）一键生成 带有 webpack 的项目
• 开箱即用，所有 webpack 配置项都是现成的
• 但是我们仍需要了解配置项的基本概念