前端工程化指的是在企业级地前端项目开发中,把前端开发所需地工具、技术、流程、经验等进行规范化、标准化。最终落实到细节上,就是实现前端地 4 个现代化:
早期地前端工程化解决方案:
目前主流地前端工程化解决方案:
# 在终端运行如下的命令,安装 webpack 相关的两个包
npm install [email protected] [email protected] -D
# mode 用来指定构建模式。可选值有 development 和 production
module.exports = {
mode: 'development'
}
# scripts 节点下的脚本,可以通过 npm run 执行。例如 npm run dev
"scripts": {
"dev": "webpack"
}
webpack.config.js 是 webpack 的配置文件。webpack 在真正开始打包构建之前,会先读取这个配置文件,从而基于给定的配置,对项目进行打包
注意:由于 webpack 是基于 node.js 开发出来的打包工具,因此在它的配置文件中,支持使用 node.js 相关的语法和模块进行 webpack 的个性化配置
webpack 中的默认约定:
自定义打包的入口与出口:
# 在 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' // 输出文件的名称
}
}
通过安装和配置第三方的插件,可以拓展 webpack 的能力,从而让 webpack 用起来更方便。最常用的 webpack 插件有如下两个:
webpack-dev-server 可以让 webpack 监听项目源代码的变化,从而进行自动打包构建
安装:
# 运行如下的命令,即可在项目中安装此插件
npm install [email protected] -D
配置:
# 修改 package.json -> scripts 中的 dev 命令如下
"scripts": {
"dev": "webpack serve"
}
webpack-dev-server 生成到内存中的文件,默认存放到了项目的根目录中,而且是虚拟的、不可见的。
html-webpack-plugin 是 webpack 中的 HTML 插件,可以通过此插件自定制 index.html 页面的内容。将 src 目录下的 index.html 首页,复制到项目根目录中一份
安装:
# 运行如下的命令,即可在项目中安装此插件
npm install [email protected] -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 插件生效
}
在 webpack.config.js 配置文件中,可以通过 devServer 节点对 webpack-dev-server 插件进行更多的配置
devServer: {
open: true, // 初次打包成功后,自动打开浏览器
host: '127.0.0.1', // 实时打包所使用的主机地址
port: 80 // 实时打包使用的端口号
}
注意:修改 webpack.config.js 配置文件,或修改 package.json 配置问价你,必须重启实时打包的服务器,否则最新的配置文件无法生效
在实际开发过程中,webpack 默认只能打包处理以 .js 后缀名结尾的模块。其他非 .js 后缀名结尾的模块,webpack 默认处理不,需要调用 loader 加载器才可以正常打包,否则会报错。
loader 加载器的作用:协助 webpack 打包处理特定的文件模块,比如:
# 所有第三方文件模块的匹配规则
module: {
# 文件后缀名的匹配规则
rules: [
{ test: /\.css$/, use: ['style-loader', 'css-loader'] }
]
}
# test 表示匹配的文件类型,use表示对应要调用的 loader
注意:
# 所有第三方文件模块的匹配规则
module: {
# 文件后缀名的匹配规则
rules: [
{ test: /\.less$/, use: ['style-loader', 'css-loader', 'less-loader'] }
]
}
# test 表示匹配的文件类型,use表示对应要调用的 loader
# 所有第三方文件模块的匹配规则
module: {
# 文件后缀名的匹配规则
rules: [
{ test: /\.jpg|png|gif$/, use: 'url-loader?limit=20000'},
]
}
其中 ? 之后的是 loader 的参数项:
带参数项的 loader 还可以通过对象的方式进行配置
# 用来处理所有的第三方模块
module: {
# 第三方模块的匹配规则
rules: [
{
test: /\.jpg|png|gif$/, // 匹配图片文件
use: {
loader: 'url-loader', // 通过 loader 属性指定要调用的 loader
options: { // 通过 options 属性指定参数项
limit: 20000
}
}
}
]
}
webpack 只能打包处理一部分高级的 JavaScript 语法。对于那些 webpack 无法处理的高级 js 语法,需要借助 babel-loader 进行打包处理,例如 webpack 无法处理下面的 JavaScript 代码:
# 通过 static 关键字,为 Person 类定义了一个静态属性 info
# webpack 无法打包处理静态属性这个高级语法
class Person {
static info = 'person info'
}
console.log(Person.info)
# 运行如下的命令安装对应的依赖包
npm i babel-loader #babel/core @babel/plugin-proposal-class-properties -D
# 在 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'],
}
}
}
项目开发完成之后,使用 webpack 对项目进行打包发布的主要原因有以下两点:
为了让项目能够在生产环境中高性能的运行,因此需要对项目进行打包发布
在 package.json 文件的 scripts 节点下,新增 build 命令如下
"scripts": {
"dev": "webpack serve", // 开发环境中,运行 dev 命令
"build": "webpack --mode production" // 项目发布时,运行 build 命令
}
–mode 是一个参数项,用来指定 webpack 的运行模式。production 代表生产环境,会对打包生成的文件进行代码压缩和性能优化。
注意:通过 --mode 指定的参数项,会覆盖 webpack.config.js 中的 mode 选项
# 在 webpack.config.js 配置文件的 output 节点中,进行如下的配置
output: {
path: path.join(__dirname, 'dist'),
filename: 'js/bundle.js'
}
# 修改 webpack.config.js 中的 url-loader 配置项,新增 outputPath 选项即可指定图片文件的输出路径
{
test: /\.jpg|png|gif$/,
use: {
loader: 'url-loader',
options: {
limit: 20000,
// 明确指定把打包生成的图片文件,存储到 dist 目录下的 image 文件夹中
outputPath: 'image'
}
}
}
为了在每次打包发布时自动清理掉 dist 目录中的旧文件,可以安装并配置 clean-webpack-plugin 插件
# 安装清理 dist 目录的 webpack 插件
npm install [email protected] -D
# 按需导入插件,得到插件的构造函数之后,创建插件的实例对象
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const cleanPlugin = new CleanWebpackPlugin()
# 把创建的 cleanPlugin 插件实例对象,挂载到 plugins 节点中
plugins: [htmlPlugin, cleanPlugin]
企业级的项目在进行打包发布时,远比刚才的方式要复杂的多,主要的发布流程如下:
前端项目在投入生产环境之前,都需要对 JavaScript 源代码进行压缩混淆,从而减小文件的体积,提高文件的加载效率。此时就不可避免地产生了另一个问题:
Source Map 就是一个信息文件,里面存储着位置信息。也就是说,Source Map 文件中存储着代码压缩混淆前后地对应关系
有了它,出错地时候,除了工具将直接显示原始代码,而不是转换后地代码,能够极大的方便后期的调试
在开发环境下,webpack 默认启用了 Source Map 功能。当程序运行出错时,可以直接在控制台提示错误行的位置,并定位到具体的源代码
问题:开发环境下默认生成的 Source Map,记录的是生成后的代码的位置,会导致运行时报错的行数与源代码的行数不一致的问题
解决:开发环境下,推荐在 webpack.config.js 中添加如下的配置,即可保证运行时报错的行数与源代码的行数保持一致
module.exports = {
mode: 'development',
# eval-source-map 仅限在开发模式下使用,不建议在生产模式下使用
# 此选项生成的 Source Map 能够保证运行时报错的行数与源代码的行数保持一致
devtool: 'eval-source-map'
}
在生产环境下,如果省略了 devtool 选项,则最终生成的文件中不包含 Source Map。这能够防止原始代码通过 Source Map 的形式暴露给别有所图之人
在生产环境下,如果只想定位报错的具体行数,且不想暴露源码。此时可以将 devtool 的值设置为 nosources-source-map
生产环境下,如果想在定位报错行数的同时,展示具体报错的源码,此时可以将 devtool 的值设置为 source-map