前端工程化与webpack1、前端工程化 1.1、什么是前端工程化前端工程化指的是在企业级地前端项目开发中，把前端开发

1、前端工程化

1.1、什么是前端工程化

前端工程化指的是在企业级地前端项目开发中，把前端开发所需地工具、技术、流程、经验等进行规范化、标准化。最终落实到细节上，就是实现前端地 4 个现代化：

模块化（js 的模块化、css 的模块化、其它资源的模块化）
组件化（复用现有的 UI 结构、样式、行为）
规范化（目录结构的划分、编码规范化、接口规范化、文档规范化、Git 分支管理）
自动化（自动化构建、自动部署、自动化测试）

1.2、前端工程化的好处

前端工程化让前端开发能够自成体系，覆盖了前端项目从创建到部署的方方面面
最大程度地提高了前端地开发效率，降低了技术选型、前后端联调等带来的协调沟通成本

1.3、前端工程化的解决方案

早期地前端工程化解决方案：

grunt（www.gruntjs.net/ ）
gulp（www.gulpjs.com.cn/ ）

目前主流地前端工程化解决方案：

webpack（www.webpackjs.com/ ）
parcel（zh.parceljs.org/ ）

2、webpack 的基本使用

2.1、什么是 webpack

webpack 是前端项目工程化的具体解决方案
它提供了友好的前端模块化开发支持，以及代码压缩混淆、处理浏览器端 JavaScript 的兼容性、性能优化等强大的功能
让程序员把工作的重心放到具体功能的实现上，提高了前端开发效率和项目的可维护性
目前企业级的前端项目开发中，绝大多数的项目都是基于 webpack 进行打包构建的

2.2、在项目中安装 webpack

# 在终端运行如下的命令，安装 webpack 相关的两个包
npm install webpack@5.5.1 webpack-cli@4.2.0 -D

2.3、在项目中配置 webpack

在项目根目录中，创建名为 webpack.config.js 的 webpack 配置文件，并初始化如下的基本配置

# mode 用来指定构建模式。可选值有 development 和 production
module.exports = {
  mode: 'development'
}

在 package.json 的 scripts 节点下，新增 dev 脚本如下：

# scripts 节点下的脚本，可以通过 npm run 执行。例如 npm run dev
"scripts": {
  "dev": "webpack"
}

在终端运行 npm run dev 命令，启动 webpack 进行项目的打包构建

2.4、mode 的可选值

development

开发环境
不会对打包生成的文件进行代码压缩和性能优化
打包速度块，适合在开发阶段使用

production

生产环境
会对打包生成的文件进行代码压缩和性能优化
打包速度很慢，仅适合在项目发布阶段使用

2.5、webpack.config.js 文件的作用

webpack.config.js 是 webpack 的配置文件。webpack 在真正开始打包构建之前，会先读取这个配置文件，从而基于给定的配置，对项目进行打包

注意：由于 webpack 是基于 node.js 开发出来的打包工具，因此在它的配置文件中，支持使用 node.js 相关的语法和模块进行 webpack 的个性化配置

webpack 中的默认约定：

默认的打包入口文件为 src -> index.js
默认的输出文件路径为 dist -> main.js

自定义打包的入口与出口：

# 在 webpack.config.js 配置文件中，通过 entry 节点指定打包的入口。通过 output 节点指定打包的出口

# 导入 node.js 中专门操作路径的模块
const path = require('path');

module.exports = {
  entry: path.join(__dirname, './src/index.js'); // 打包入口的路径
  output: {
    path: path.join(__dirname, './dist'), // 输出文件的存放路径
    filename: 'bundle.js' // 输出文件的名称
  }
}

3、webpack 中的插件

3.1、webpack 插件的作用

通过安装和配置第三方的插件，可以拓展 webpack 的能力，从而让 webpack 用起来更方便。最常用的 webpack 插件有如下两个：

webpack-dev-server

类似于 node.js 阶段用到的 nodemon 工具
每当修改了源代码，webpack 会自动进行项目的打包和构建

html-webpack-plugin

webpack 中的 HTML 插件（类似于一个模板引擎插件）
可以通过此插件自定制 index.html 页面的内容

3.2、webpack-dev-server

webpack-dev-server 可以让 webpack 监听项目源代码的变化，从而进行自动打包构建

安装：

# 运行如下的命令，即可在项目中安装此插件
npm install webpack-dev-server@3.11.0 -D

配置：

# 修改 package.json -> scripts 中的 dev 命令如下
"scripts": {
  "dev": "webpack serve"
}

再次运行 npm run dev 命令，重新进行项目的打包
在浏览器中访问 http://localhost:8080 地址，查看自动打包效果
webpack-dev-server 会启动一个实时打包的 http 服务器

3.3、打包生成的文件去哪了？

不配置 webpack-dev-server 的情况下，webpack 打包生成的文件，会存放到实际的物理磁盘上

严格遵守开发者在 webpack.config.js 中指定配置
根据 output 节点指定路径进行存放

配置了 webpack-dev-server 之后，打包生成的文件存放到了内存中

不再根据 output 节点指定的路径，存放到实际的物理磁盘上
提高了实时打包输出的性能，因为内存比物理磁盘速度快很多

3.4、生成到内存中的文件该如何访问

webpack-dev-server 生成到内存中的文件，默认存放到了项目的根目录中，而且是虚拟的、不可见的。

可以直接用 / 表示项目根目录，后面跟上要访问的文件名称，即可访问内容中的文件
例如 /bundle.js 就表示要访问 webpack-dev-server 生成到内存中的 bundle.js 文件

3.5、html-webpack-plugin

html-webpack-plugin 是 webpack 中的 HTML 插件，可以通过此插件自定制 index.html 页面的内容。将 src 目录下的 index.html 首页，复制到项目根目录中一份

安装：

# 运行如下的命令，即可在项目中安装此插件
npm install html-webpack-plugin@4.5.0 -D

配置：

# 导入 HTML 插件，得到一个构造函数
const HtmlPlugin = require('html-webpack-plugin');

# 创建 HTML 插件的实例对象
const htmlPlugin = new HtmlPlugin({
  template: './src/index.html', // 指定原文件的存放路径
  filename: './index.html', // 指定生成的文件的存放路径
});

module.exports = {
  mode: 'development',
  plugin: [htmlPlugin], // 通过 plugins 节点，使 htmlPlugin 插件生效
}

通过 HTML 插件复制到项目根目录中的 index.html 页面，也被放到了内存中
HTML 插件在生成的 index.html 页面的底部，自动注入了打包的 bundle.js 文件

3.6、devServer 节点

在 webpack.config.js 配置文件中，可以通过 devServer 节点对 webpack-dev-server 插件进行更多的配置

devServer: {
  open: true, // 初次打包成功后，自动打开浏览器
  host: '127.0.0.1', // 实时打包所使用的主机地址
  port: 80 // 实时打包使用的端口号
}

注意：修改 webpack.config.js 配置文件，或修改 package.json 配置问价你，必须重启实时打包的服务器，否则最新的配置文件无法生效

4、webpack 中的 loader

4.1、loader 概述

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

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

css-loader 可以打包处理 .css 相关的文件
less-loader 可以打包处理 .less 相关的文件
babel-loader 可以打包处理 webpack 无法处理的高级 JS 语法

4.2、打包处理 css 文件

运行 npm i style-loader@2.0.0 css-loader@5.0.1 -D 命令，安装处理 css 文件的 loader
在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

# 所有第三方文件模块的匹配规则
module: {
  # 文件后缀名的匹配规则
  rules: [
    { test: /\.css$/, use: ['style-loader', 'css-loader'] }
  ]
}
# test 表示匹配的文件类型，use表示对应要调用的 loader

注意：

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

4.3、打包处理 less 文件

运行 npm i less-loader less -D 命令
在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

# 所有第三方文件模块的匹配规则
module: {
  # 文件后缀名的匹配规则
  rules: [
    { test: /\.less$/, use: ['style-loader', 'css-loader', 'less-loader'] }
  ]
}
# test 表示匹配的文件类型，use表示对应要调用的 loader

4.4、打包处理样式表中与 url 路径相关的文件

运行 npm i url-loader file-loader -D 命令
在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下：

# 所有第三方文件模块的匹配规则
module: {
  # 文件后缀名的匹配规则
  rules: [
    { test: /\.jpg|png|gif$/, use: 'url-loader?limit=20000'},
  ]
}

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

limit 用来指定图片的大小，单位是字节（byte）
只有 <= limit 大小的图片，才会被转为 base64 格式的图片

4.5、loader 的另一种配置方式

带参数项的 loader 还可以通过对象的方式进行配置

# 用来处理所有的第三方模块
module: {
  # 第三方模块的匹配规则
  rules: [
    {
      test: /\.jpg|png|gif$/, // 匹配图片文件
      use: {
        loader: 'url-loader', // 通过 loader 属性指定要调用的 loader
        options: { // 通过 options 属性指定参数项
          limit: 20000
        }
      }
    }
  ]
}

4.6、打包处理 js 文件中的高级语法

webpack 只能打包处理一部分高级的 JavaScript 语法。对于那些 webpack 无法处理的高级 js 语法，需要借助 babel-loader 进行打包处理，例如 webpack 无法处理下面的 JavaScript 代码：

# 通过 static 关键字，为 Person 类定义了一个静态属性 info
# webpack 无法打包处理静态属性这个高级语法
class Person {
  static info = 'person info'
}
console.log(Person.info)

4.6.1 安装 babel-loader 相关的包

# 运行如下的命令安装对应的依赖包
npm i babel-loader #babel/core @babel/plugin-proposal-class-properties -D

4.6.2 配置 babel-loader

# 在 webpack.config.js 的 module -> rules 数组中，添加 loader 规则如下
{
  test: /\.js$/
  # exclude 为排除项，表示 babel-loader 只需处理开发者编写的 js 文件，不需要处理 node_modules 下的 js 文件
  exclude: /node_modules/,
  use: {
    loader: 'babel-loader',
    options: {
      # 声明一个 babel 插件，此插件用来转化 class 中的高级语法
      plugins: ['@babel/plugin-proposal-class-properties'],
    }
  }
}

5、打包发布

5.1、为什么要打包发布

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

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

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

5.2、配置 webpack 的打包发布

在 package.json 文件的 scripts 节点下，新增 build 命令如下
"scripts": {
  "dev": "webpack serve", // 开发环境中，运行 dev 命令
  "build": "webpack --mode production" // 项目发布时，运行 build 命令
}

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

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

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

# 在 webpack.config.js 配置文件的 output 节点中，进行如下的配置
output: {
  path: path.join(__dirname, 'dist'),
  filename: 'js/bundle.js'
}

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

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

{
  test: /\.jpg|png|gif$/,
  use: {
    loader: 'url-loader',
    options: {
      limit: 20000,
      // 明确指定把打包生成的图片文件，存储到 dist 目录下的 image 文件夹中
      outputPath: 'image'
    }
  }
}

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

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

# 安装清理 dist 目录的 webpack 插件
npm install clean-webpack-plugin@3.0.0 -D

# 按需导入插件，得到插件的构造函数之后，创建插件的实例对象
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const cleanPlugin = new CleanWebpackPlugin()

# 把创建的 cleanPlugin 插件实例对象，挂载到 plugins 节点中
plugins: [htmlPlugin, cleanPlugin]

5.6、企业级项目的打包发布

企业级的项目在进行打包发布时，远比刚才的方式要复杂的多，主要的发布流程如下：

生成打包报告，根据报告分析具体的优化方案
Tree-Shaking
为第三方库启用 CDN 加载
配置组件的按需加载
开启路由懒加载
自定制首页内容

6、Source Map

6.1、生产环境遇到的问题

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

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

6.2、什么是 Source Map

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

6.3、webpack 开发环境下的 Source Map

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

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

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

module.exports = {
  mode: 'development',
  # eval-source-map 仅限在开发模式下使用，不建议在生产模式下使用
  # 此选项生成的 Source Map 能够保证运行时报错的行数与源代码的行数保持一致
  devtool: 'eval-source-map'
}

6.4、webpack 生产环境下的 Source Map

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

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

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

6.6、定位行数且暴露源码

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

6.7、Source Map 的最佳实践

开发环境下

建议把 devtool 的值设置为 eval-source-map
好处：可以精确定位到具体的错误行

生产环境下

建议关闭 Source Map 或将 devtool 的值设置为 nosources-source-map
好处：防止源码泄露，提高网站的安全性

前端工程化与webpack