1. 前端工程化
1.1 实际的前端开发
实际的前端开发:
-
模块化(js 的模块化、css 的模块化、资源的模块化)
-
组件化(复用现有的UI 结构、样式、行为)
-
规范化(目录结构的划分、编码规范化、接口规范化、文档规范化、Git 分支管理)
-
自动化(自动化构建、自动部署、自动化测试)
1.2 什么是前端工程化
前端工程化指的是:在企业级的前端项目开发中,把前端开发所需的工具、技术、流程、经验等进行规范化、标准化。
企业中的 Vue 项目和 React 项目,都是基于工程化的方式进行开发的。
好处:前端开发自成体系,有一套标准的开发方案和流程。
1.3 前端工程化的解决方案
早期的前端工程化解决方案:
目前主流的前端工程化解决方案:
2. webpack 的基本使用
2.1 什么是 webpack
概念:webpack 是前端项目工程化的具体解决方案。
主要功能:它提供了友好的前端模块化开发支持,以及代码压缩混淆、处理浏览器端 JS 的兼容性、性能优化等强大的功能。
好处:让程序员把工作的重心放到具体功能的实现上,提高了前端开发效率和项目的可维护性。
注意:目前 Vue,React 等前端项目,基本上都是基于 webpack 进行工程化开发的。
2.2 创建列表隔行变色项目
2.2.1 项目初始化
新建项目空白目录,并运行 npm init –y 命令,初始化包管理配置文件 package.json 。
初始化项目命令:
npm init -y
初始化产生的 package.json,如下图所示:
{
"name": "01webpack",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [],
"author": "",
"license": "ISC"
}
2.2.2 建文件
新建 src 源代码目录。
新建 src -> index.html 首页和 src -> index.js 脚本文件。
2.2.3 安装包
运行 npm install jquery –S 命令,安装 jQuery 。
运行 npm install webpack webpack-cli –D 命令,安装 webpack webpack-cli 。
-S 是 --save 的简写
-D 是 --save-dev 的简写
2.2.4 代码逻辑
初始化首页基本的结构,并将列表内容写完整。
index.html 内容如下:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<ul>
<li>这是第1行</li>
<li>这是第2行</li>
<li>这是第3行</li>
<li>这是第4行</li>
<li>这是第5行</li>
<li>这是第6行</li>
<li>这是第7行</li>
<li>这是第8行</li>
</ul>
</body>
</html>
通过 ES6 模块化的方式导入 jQuery,再将 index.js 自行导入到 index.html ,实现列表隔行变色效果。
index.js 内容如下:
import $ from 'jquery'
$(function () {
$('li:odd').css('background-color', 'red')
$('li:even').css('background-color', 'blue')
})
2.2.5 webpack 配置
在项目根目录中,创建名为 webpack.config.js 的 webpack 配置文件,并初始化如下的基本配置:
webpack.config.js 内容如下:
module.exports = {
mode: "development"
}
mode 节点的可选值有两个,分别是:
-
development
- 开发环境
- 不会对打包生成的文件进行代码压缩和性能优化
- 打包速度快,适合在开发阶段使用
-
production
- 生产环境
- 会对打包生成的文件进行代码压缩和性能优化
- 打包速度很慢,仅适合在项目发布阶段使用
在 package.json 的 scripts 节点下,新增 dev 脚本如下:
"scripts": {
"dev": "webpack"
}
dev 只是一个脚本名,这个名字可以自己自定义。
在终端中运行 npm run 脚本名 命令,启动 webpack 进行项目的打包构建:
以本例来说:
npm run dev
2.2.6 webpack 生成的 js 导入
在 index.html 文件中导入由 webpack 重新构建的在 dist 文件夹下的 main.js 文件。
<script src="../dist/main.js"></script>
2.3 webpack.config.js 文件的作用
webpack.config.js 是 webpack 的配置文件。webpack 在真正开始打包构建之前,会先读取这个配置文件,从而基于给定的配置,对项目进行打包。
注意:由于 webpack 是基于 node.js 开发出来的打包工具,因此在它的配置文件中,支持使用 node.js 相关的语法和模块进行 webpack 的个性化配置。
2.4 使用 webpack 的疑问
- 为什么它能够知道我需要将
src文件夹的index.js打包 - 为什么打包的结果会输出在
dist文件夹的main.js文件 - 配置一定要在
webpack.config.js的文件进行配置吗? - 以上是否可以进行更改?
以上是因为默认规定。
2.5 webpack 中的默认约定
在 webpack 4.x 和 5.x 的版本中,有如下的默认约定:
-
默认的打包入口文件为
src -> index.js -
默认的输出文件路径为
dist -> main.js
注意:可以在 webpack.config.js 中修改打包的默认约定
2.6 自定义打包入口出口
在 webpack.config.js 配置文件中,通过 entry 节点指定打包的入口。通过 output 节点指定打包的出口。
webpack.config.js 示例代码如下:
const path = require('path')
module.exports = {
mode: "development",
entry: path.join(__dirname, './src/index2.js'), // 入口
// 出口
output: {
path: path.join(__dirname, './dist2'),
filename: 'index22.js'
}
}
3. webpack 中的插件
3.1 常用插件
通过安装和配置第三方的插件,可以拓展 webpack 的能力,从而让 webpack 用起来更方便。最常用的 webpack 插件有 webpack-dev-server:
-
类似于
node.js阶段用到的nodemon工具 -
每当修改了源代码,
webpack会自动进行项目的打包和构建
插件下载
npm i webpack-dev-server html-webpack-plugin -D
3.2 webpack-dev-server
3.2.1 配置
webpack-dev-server 可以让 webpack 监听项目源代码的变化,从而进行自动打包构建。
配置插件:
修改 package.json -> scripts 中的 dev 命令如下:
"scripts": {
"dev": "webpack serve"
}
再次运行 npm run dev 命令,重新进行项目的打包。
在浏览器中访问 http://localhost:8080 地址,查看自动打包效果
注意:
-
webpack-dev-server会启动一个实时打包的http服务器 -
可能是版本问题,
src文件夹和代码中的src改为public才可使用(如果原来的src文件夹不会报错,可以不用更改)
3.2.2 打包生成的文件哪儿去了?
-
不配置
webpack-dev-server的情况下,webpack打包生成的文件,会存放到实际的物理磁盘上-
严格遵守开发者在
webpack.config.js中指定配置 -
根据
output节点指定路径进行存放
-
-
配置了
webpack-dev-server之后,打包生成的文件存放到了内存中-
不再根据
output节点指定的路径,存放到实际的物理磁盘上 -
提高了实时打包输出的性能,因为内存比物理磁盘速度快很多
-
3.2.3 生成到内存中的文件该如何访问?
webpack-dev-server 生成到内存中的文件,默认放到了项目的根目录中,而且是虚拟的、不可见的。
-
可以直接用
/表示项目根目录,后面跟上要访问的文件名称,即可访问内存中的文件 -
例如
/index22.js就表示要访问webpack-dev-server生成到内存中的index22.js文件
3.2.4 devServer节点
在 webpack.config.js 配置文件中,可以通过 devServer 节点对 webpack-dev-server 插件进行更多的配置,
示例代码如下:
devServer: {
open: true, // 初次打包完成后,自动打开浏览器
host: '127.0.0.1', // 实时打包的主机地址
port: 8001 // 实事打包使用的端口号
}
注意:凡是修改了 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 loader 的调用
4.3 打包 CSS
下载对应的 loader:
npm i style-loader css-loader -D
在 webpack.config.js 的 module-> rules 数组中,添加 loader 规则如下:
module: {
rules: [
{ test: /\.css$/, usse: ['css-loader'] }
]
}
其中,test 表示匹配的文件类型,use 表示对应要调用的 loader
注意:
-
use 数组中指定的
loader顺序是固定的 -
多个
loader的调用顺序是:从后往前调用
4.4 打包处理 less 文件
下载对应的 loader:
npm i less-loader less -D
在 webpack.config.js 的 module-> rules 数组中,添加 loader 规则如下:
module: {
rules: [
{ test: /\.css$/, use: ['style-loader', 'css-loader'] },
{ test: /\.less$/, use: ['style-loader', 'css-loader', 'less-loader'] }
]
}
其中,test 表示匹配的文件类型,use 表示对应要调用的 loader
注意:
-
use数组中指定的loader顺序是固定的 -
多个
loader的调用顺序是:从后往前调用
4.5 打包处理样式表中与 url 路径相关的文件
4.5.1 概述
下载对应的 loader:
npm i url-loader file-loader -D
在 webpack.config.js 的 module-> rules 数组中,添加 loader 规则如下:
module: {
rules: [
{ test: /\.css$/, use: ['style-loader', 'css-loader'] },
{ test: /\.less$/, use: ['style-loader', 'css-loader', 'less-loader'] },
// 多个 loader 要[],一个loader 是字符串
{ test: /\.jpg|png|gif$/, use: 'url-loader?limit=222' }
]
}
其中 ? 之后的是 loader 的参数项:
-
limit用来指定图片的大小,单位是字节(byte) -
只有
≤ limit大小的图片,才会被转为base64格式的图片
4.5.2 base64 编码
图片的 base64编码 主要是为了用在网页上减少请求次数。
我们都知道,我们的网站采用的都是 http 协议,而 http 协议是一种无状态的连接,就是连接和传输后都会断开连接节省资源。此时解决的方法就是尽量的减少 http 请求,此时 base64编码 可以将图片添加到 css 中,实现请求 css 即可下载下来图片,减少了再次请求图片的请求。
当然减少 http 请求次数的方法还有很多,如精灵图(雪碧图)技术,将网页中的小图片拼在一张大图中,下载时只需要一次完整的 http 请求就可以,减少了请求次数。
4.6 打包处理 JS 文件中的高级语法
4.6.1 无法处理的高级语法
webpack 只能打包处理一部分高级的 JS 语法。对于那些 webpack 无法处理的高级 JS 语法,需要借助于 babel-loader 进行打包处理。例如 webpack 无法处理下面的 JS 代码:
function info(target) {
target.info = 'Person info'
}
@info // 装饰器
class Person { }
console.log(Person.info)
4.6.2 配置 babel-loader
下载对应的 loader:
npm i babel-loader @babel/core @babel/plugin-proposal-decorators -D
在项目根目录下,创建名为 babel.config.js 的配置文件,定义 Babel 的配置项如下:
module.exports = {
plugins: [['@babel/plugin-proposal-decorators', { legacy: true }]]
}
在 webpack.config.js 的 module-> rules 数组中,添加 loader 规则如下:
module: {
rules: [
{ test: /\.css$/, use: ['style-loader', 'css-loader'] },
{ test: /\.less$/, use: ['style-loader', 'css-loader', 'less-loader'] },
// 多个 loader 要[],一个loader 是字符串
{ test: /\.jpg|png|gif$/, use: 'url-loader?limit=222' },
// 必须使用 exclude 指定排除项,因为 node_modules 目录下的第三方包不需要被打包(不关心其兼容问题)
{ test: /\.js$/, use: 'babel-loader', exclude: /node_modules/ }
]
}
5. 打包发布
5.1 为什么要打包发布
项目开发完成之后,需要使用 webpack 对项目进行打包发布,主要原因有以下两点:
-
开发环境下,打包生成的文件存放于内存中,无法获取到最终打包生成的文件
-
开发环境下,打包生成的文件不会进行代码压缩和性能优化
为了让项目能够在生产环境中高性能的运行,因此需要对项目进行打包发布。
5.2 webpack 的打包发布
在 package.json 文件的 scripts 节点下,新增 build 命令如下(本质就是再写了个脚本):
"scripts": {
"dev": "webpack serve",
"build": "webpack --mode production"
}
--model 是一个参数项,用来指定 webpack 的运行模式。production 代表生产环境,会对打包生成的文件进行代码压缩和性能优化。这样不用频繁切换 webpack.config.js 中的配置。
注意:通过 --model 指定的参数项,会覆盖 webpack.config.js 中的 model 选项。
5.3 统一目录
5.3.1 统一到 js 目录
在 webpack.config.js 配置文件的 output 节点中,进行如下的配置:
output: {
path: path.join(__dirname, './dist2'),
filename: 'js/index22.js' // 这里指定文件到 js 目录
}
5.3.2 把图片文件统一生成到 image 目录中
修改 webpack.config.js 中的 url-loader 配置项,新增 outputPath 选项即可指定图片文件的输出路径:
{ test: /\.jpg|png|gif$/, use: 'url-loader?limit=222&outputPath=image' }
5.3.3 自动清理 dist 目录(出口目录)下的旧文件
为了在每次打包发布时自动清理掉 dist 目录(出口目录)中的旧文件,我们需要再 webpack.config.js 中的 output 定义 clean: true ,
output: {
path: path.join(__dirname, './dist2'),
filename: 'js/index22.js',
clean: true
}
5.4 @ 优化
当我们文件层级(主要是 public 或 src 文件)比较深时,在导入浅层文件时。我们之前需要用相对路径去表示路径,这时候导入的文件就相对没那么清晰,我们可以使用 @ 来指定为 public 或 src 文件夹。
我们需要再 webpack.config.js 设置:
resolve: {
alias: {
'@': path.join(__dirname, './public/') // public 文件夹等同于 @
}
}
这样的好处具体体现在,使文件结构更加清晰。
比如:public 下有个 js 文件夹 和 1.js 文件,js 文件夹 有个 2.js 文件。
如果 2.js 中导入 1.js 文件,需要这样导入 ../1.js
用了 @ 之后我们可以这样导入,@/1.js
文件层级越深,用 @ 表示的好处就越明显。
6. Source Map
6.1 生产环境遇到的问题
前端项目在投入生产环境之前,都需要对 JS 源代码进行压缩混淆,从而减小文件的体积,提高文件的加载效率。此时就不可避免的产生了另一个问题,对压缩混淆之后的代码除错(debug)是一件极其困难的事情,因为:
-
变量被替换成没有任何语义的名称
-
空行和注释被剔除
6.2 什么是 Source Map
Source Map 就是一个信息文件,里面储存着位置信息。也就是说,Source Map 文件中存储着压缩混淆后的代码,所对应的转换前的位置。
有了它,出错的时候,除错工具将直接显示原始代码,而不是转换后的代码,能够极大的方便后期的调试。
6.3 webpack 开发环境下的 Source Map
在开发环境下,webpack 默认启用了 Source Map 功能。当程序运行出错时,可以直接在控制台提示错误行的位置,并定位到具体的源代码。但是,开发环境下默认生成的 Source Map,记录的是生成后的代码的位置。会导致运行时报错的行数与源代码的行数不一致的问题。
6.4 开发环境解决默认 Source Map 的问题
开发环境下,推荐在 webpack.config.js 中添加如下的配置,即可保证运行时报错的行数与源代码的行数保持一致:
module.exports = {
mode: 'develoment',
devtool: 'eval-source-map'
}
6.5 生产环境解决默认 Source Map 的问题
在生产环境下,如果省略了 devtool 选项,则最终生成的文件中不包含 Source Map。这能够防止原始代码通过 Source Map 的形式暴露给别有所图之人。
在生产环境下,如果只想定位报错的具体行数,且不想暴露源码。此时可以将 devtool 的值设置为 nosources-source-map。
如果想在定位报错行数的同时,展示具体报错的源码。此时可以将 devtool 的值设置为 source-map。
注意:设置为 source-map 时,你应该将你的服务器配置为,不允许普通用户访问 source map 文件
6.6 Source Map 的最佳实践
开发环境下:
-
建议把
devtool的值设置为eval-source-map -
好处:可以精准定位到具体的错误行
生产环境下:
-
建议关闭
Source Map或将devtool的值设置为nosources-source-map -
好处:防止源码泄露,提高网站的安全性
如有错误,敬请指正,欢迎交流🤝,谢谢♪(・ω・)ノ