前端工程化
小白眼中的前端开发:
- 会写 HTML CSS JavaScript 就会前端开发
- 需要美化页面样式,就拽一个 bootstrap 过来
- 需要操作 DOM 或发起 Ajax 请求,再拽一个 jQuery 过来
- 需要渲染模板结构,就用 art-template 等模板引擎
实际的前端开发:
- 模块化(js 的模块化、css 的模块化、其它资源的模块化)
- 组件化(复用现有的 UI 结构、样式、行为)
- 规范化(目录结构的划分、编码规范化、接口规范化、文档规范化、 Git 分支管理)
- 自动化(自动化构建、自动部署、自动化测试
前端工程化指的是:在企业级的前端项目开发中,把前端开发所需的工具、技术、流程、经验等进行规范化、 标准化。最终落实到细节上,就是实现前端的“4 个现代化”: 模块化、组件化、规范化、自动化
前端工程化的好处
前端工程化的好处主要体现在如下两方面:
① 前端工程化让前端开发能够“自成体系”,覆盖了前端项目从创建到部署的方方面面
② 最大程度地提高了前端的开发效率,降低了技术选型、前后端联调等带来的协调沟通成本
前端工程化的解决方案
早期的前端工程化解决方案:
- grunt( https://www.gruntjs.net/ )
- gulp( https://www.gulpjs.com.cn/ )
目前主流的前端工程化解决方案:
- webpack( https://www.webpackjs.com/ )
- parcel( https://zh.parceljs.org/ )
webpack的基本使用
什么是webpack
概念:webpack是前端项目工程化的具体解决方案。
主要功能:它提供了友好的前端模块化开发支持,以及代码压缩混淆、处理浏览器端JavaScript的兼容性、性能优化等强大的功能。
好处:让程序员把工作的重心放到具体功能的实现上,提高了前端开发效率和项目的可维护性。
注意:目前企业级的前端项目开发中,绝大多数的项目都是基于webpack进行打包构建的。
创建列表隔行变色项目
① 新建项目空白目录,并运行 npm init –y
命令,初始化包管理配置文件 package.json
② 新建 src 源代码目录
③ 新建 src -> index.html 首页和 src -> index.js 脚本文件
④ 初始化首页基本的结构
⑤ 运行 npm install jquery –S
命令,安装 jQuery
⑥ 通过 ES6 模块化的方式导入 jQuery,实现列表隔行变色效果
在项目中安装webpack
在终端运行如下的命令,安装webpack相关的两个包:
代码语言:javascript复制npm install webpack@5.5.1 webpack-cli@4.2.0 -D
在项目中配置webpack
① 在项目根目录中,创建名为 webpack.config.js
的webpack配置文件,并初始化如下的基本配置:
module.exports = {
mode:'development' //mode用来指定构建模式,可选值有development和production
}
② 在 package.json
的script节点下,新增dev脚本如下:
“script”:{
"dev":"webpack" //script节点下的脚本,可以通过npm run 执行,例如npm run dev
}
③ 在终端中运行 npm run dev
命令,启动webpack进行项目的打包构建。
mode的可选值
mode节点的可选值有俩个,分别是:
- development
- 开发环境
- 不会对打包生成的文件进行代码压缩和性能优化
- 打包速度快,适合在开发阶段使用
- production
- 生产环境
- 会对打包生成的文件进行代码压缩和性能优化
- 打包速度很慢,仅适合在项目发布阶段使用
webpack.config.js文件的作用
webpack.config.js
是webpack的配置文件,webpack在真正开始打包构建之前,会先读取这个配置文件,从而基于给定的配置,对项目进行打包。
注意:由于webpack是基于node.js开发出来的打包工具,因此在它的配置文件中,支持使用node.js相关的语法和模块进行webpack的个性化配置。
webpack的默认约定
在webpack中有如下的默认约定:
- 默认的打包入口文件为
src -> index.js
- 默认的输出文件路径为
dist -> main.js
注意:可以在 webpack.config.js
中修改打包的默认约定
自定义打包的入口和出口
在webpack.config.js配置文件中,通过entry节点指定打包的入口。通过output节点指定打包的出口。
代码语言:javascript复制const path = require('path') //导入node.js中专门操作路径的模块
module.exports = {
entry:path.join(__dirname,'./src/index.js'), //打包入口文件的路径
output:{
path:path.join(__dirname,'./dist'),//输出文件的存放路径
filename:'bundle.js' //输出文件的名称
}
}
webpack中的插件
wepack插件的作用
通过安装和配置第三方的插件,可以拓展webpack的能力,从而让webpack用起来更方便。最常用的webpack插件有如下两个:
① webpack-dev-server
- 类似于node.js阶段用到的nodemon工具
- 每当修改了源代码,webpack会自动进行项目的打包和构建
② html-webpack-plugin
- webpack中的HTML插件(类似于一个模板引擎插件)
- 可以通过此插件子定制index.html页面的内容
webpack-dev-server
webpack-dev-server
可以让webpack监听项目源代码的变化,从而进行自动打包构建。
安装webpack-dev-server
代码语言:javascript复制npm install webpack-dev-server@3.11.0 -D
配置webpack-dev-server
① 修改package.json -> script中的dev命令如下:
代码语言:javascript复制“script”:{
"dev":"webpack serve" //script节点下的脚本,可以通过npm run执行
}
② 再次运行 npm run dev
命令,重新进行项目的打包
③ 在浏览器中访问 http://127.0.0.1:8080 地址,查看自动打包效果。
注意:webpack-dev-server
会启动一个实时打包的http服务器
打包生成的文件位置
① 不配置 webpack-dev-server
的情况下,webpack打包生成的文件,会存放到实际的物理磁盘上
- 严格遵守开发者在
webpack.config.js
中指定配置 - 根据
output
节点指定路径进行存放
② 配置了 webpack-dev-server
之后,打包生成的文件存放到了内存中
- 不再根据
output
节点指定的路径,存放到实际的物理磁盘上 - 提高了实时打包输出的性能,因为内存比物理磁盘速度快很多
访问生成到内存中的文件
webpack-dev-server
生成到内存中的文件,默认放到了项目的根目录中,而且是虚拟的、不可见的。
- 可以直接使用
/
表示项目根目录,后面跟上要访问的文件名称,即可访问内存中的文件 - 例如
/bundle.js
就表示要访问webpack-dev-server
生成到内存中的bundle.js
文件
html-webpack-plugin
html-webpack-plugin
是 webpack 中的 HTML 插件,可以通过此插件自定制 index.html 页面的内容。
需求:通过 html-webpack-plugin
插件,将 src 目录下的 index.html 首页,复制到项目根目录中一份!
安装html-webpack-plugin
运行如下的命令,即可在项目中安装此插件:
代码语言:javascript复制npm install html-webpack-plugin@4.5.0 -D
配置html-webpack-plugin
在 webpack.config.js
中进行如下配置:
// 1. 导入插件,得到构造函数
const HtmlPlugin = require('html-webpack-plugin')
// 2. 创建插件的实例对象
const htmlPlugin = new HtmlPlugin({
template: './src/index.html',
filename: './index.html',
})
module.exports = {
mode:'development',
plugins:[htmlPlugin],//3.通过plugins节点,使htmlPlugin插件生效
}
解惑html-webpack-plugin
- 通过HTML插件复制到项目根目录的index.html页面,也被放到了内存中
- HTML插件在生成的index.html页面的底部,自动注入了打包的bundle.js文件
devServer节点
在 webpack.config.js
配置文件中,可以通过 devServer 节点对 webpack-dev-server
插件进行更多的配置, 示例代码如下:
devServer: {
open: true,
host: '127.0.0.1',
port: 80,
}
注意:凡是修改了 webpack.config.js
配置文件,或修改了 package.json
配置文件,必须重启实时打包的服 务器,否则最新的配置文件无法生效!
webpack中的loader
loader概述
在实际开发过程中,webpack 默认只能打包处理以 .js
后缀名结尾的模块。其他非 .js
后缀名结尾的模块, webpack 默认处理不了,需要调用 loader 加载器才可以正常打包,否则会报错!
loader 加载器的作用:协助 webpack 打包处理特定的文件模块。
比如:
css-loader
可以打包处理.css
相关的文件less-loader
可以打包处理.less
相关的文件babel-loader
可以打包处理 webpack 无法处理的高级 JS 语法
loader的调用过程
打包处理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的调用顺序是:从后往前调用
打包处理less文件
① 运行 npm i less-loader@7.1.0 less@3.12.2 -D
命令
② 在 webpack.config.js
的 module -> rules
数组中,添加 loader 规则如下:
module:{
rules:[
{test:/.less$/.use:['style-loader','css-loader','less-loader']}
]
}
打包处理样式表中与url路径相关的文件
① 运行 npm i url-loader@4.1.1 file-loader@6.2.0 -D
命令
② 在 webpack.config.js
的 module -> rules
数组中,添加 loader 规则如下:
module:{
rules:[
{test:/.jpg|png|gif$/.use:['url-loader?limt=2229']}
]
}
其中 ?
之后的是 loader 的参数项:
- limit 用来指定图片的大小,单位是字节(byte)
- 只有 ≤ limit 大小的图片,才会被转为 base64 格式的图片
loader 的另一种配置方式
带参数项的loader还可以通过对象的方式进行配置:
代码语言:javascript复制{
test: /.jpg|png|gif$/,
use: {
loader: 'url-loader',//通过loader属性指定要调用的loader
options: {//通过options属性指定参数项
limit: 22228
}
}
}
打包处理js文件中的高级语法
webpack 只能打包处理一部分高级的 JavaScript 语法。对于那些 webpack 无法处理的高级 js 语法,需要借 助于 babel-loader 进行打包处理。
安装babel-loader相关的包
运行如下的命令安装对应的依赖包:
代码语言:javascript复制npm i babel-loader@8.2.1 @babel/core@7.12.3 @babel/plugin-proposal-class-properties@7.12.1 -D
包的名称及版本号列表如下(红色是包的名称、黑色是包的版本号):
- babel-loader@8.2.1
- @babel/core@7.12.3
- @babel/plugin-proposal-class-properties@7.12.1
配置babel-loader
在 webpack.config.js
的 module -> rules
数组中,添加 loader 规则如下:
{
test: /.js$/,
//exclude为排除项,表示babel-loader只需处理开发者编写的js文件,不需要处理node_modulse下的js文件
exclude: /node_modules/,
use: {
loader: 'babel-loader',
options: {//参数项
//声明一个babel插件,此插件用来转化class中的高级语法
plugins: ['@babel/plugin-proposal-class-properties'],
},
},
}
打包发布
项目开发完成之后,使用 webpack 对项目进行打包发布的主要原因有以下两点:
① 开发环境下,打包生成的文件存放于内存中,无法获取到最终打包生成的文件
② 开发环境下,打包生成的文件不会进行代码压缩和性能优化
为了让项目能够在生产环境中高性能的运行,因此需要对项目进行打包发布。
配置webpack的打包发布
在 package.json
文件的 scripts 节点下,新增 build 命令如下:
"scripts": {
"dev": "webpack serve",
"build": "webpack --mode production"//项目发布时,运行build命令
}
--model
是一个参数项,用来指定 webpack 的运行模式。
production
代表生产环境,会对打包生成的文件 进行代码压缩和性能优化。
注意:通过 --model
指定的参数项,会覆盖 webpack.config.js
中的 model 选项
把js文件统一到js目录中
在 webpack.config.js
配置文件的 output 节点中,进行如下的配置:
output: {
// 表示输出文件的存放路径
path: path.join(__dirname, './dist'),
// 明确告诉webpack把生成的bundle.js存放到dist目录下的js子目录中
filename: 'js/bundle.js',
}
把图片文件统一到image目录中
修改 webpack.config.js
中的 url-loader
配置项,新增 outputPath 选项即可指定图片文件的输出路径:
{
test: /.jpg|png|gif$/,
use: {
loader: 'url-loader',
options: {
limit: 22228,
//明确指定把打包生成的图片文件存放到dist目录下的image文件夹中
outputPath: 'image',
},
},
}
自动清理 dist 目录下的旧文件
为了在每次打包发布时自动清理掉 dist 目录中的旧文件,可以安装并配置 clean-webpack-plugin 插件:
安装清理dist目睹了的webpack插件:
代码语言:javascript复制npm install clean-webpack-plugin@3.0.0 -D
然后按需导入插件、得到插件的构造函数后,创建插件的实例对象。
代码语言:javascript复制const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const cleanPlugin = new CleanWebpackPlugin()
把创建的 cleanPlugin
插件实例对象,挂载到 plugins
节点中。
plugins: [htmlPlugin, cleanPlugin],
企业级项目的打包发布
企业级的项目在进行打包发布时,远比刚才的方式要复杂的多,主要的发布流程如下:
- 生成打包报告,根据报告分析具体的优化方案
- Tree-Shaking
- 为第三方库启用 CDN 加载
- 配置组件的按需加载
- 开启路由懒加载
- 自定制首页内容
Source Map
前端项目在投入生产环境之前,都需要对 JavaScript 源代码进行压缩混淆,从而减小文件的体积,提高文件的加载效率。
此时就不可避免的产生了另一个问题: 对压缩混淆之后的代码除错(debug)是一件极其困难的事情。
Source Map 就是一个信息文件,里面储存着位置信息。也就是说,Source Map 文件中存储着代码压缩混淆前后的对应关系。
有了它,出错的时候,除错工具将直接显示原始代码,而不是转换后的代码,能够极大的方便后期的调试。
在开发环境下,webpack 默认启用了 Source Map 功能。当程序运行出错时,可以直接在控制台提示错误行 的位置,并定位到具体的源代码。
开发环境下默认生成的 Source Map,记录的是生成后的代码的位置。会导致运行时报错的行数与源代码的行 数不一致的问题。
解决默认Source Map的问题
开发环境下,推荐在 webpack.config.js 中添加如下的配置,即可保证运行时报错的行数与源代码的行数 保持一致:
代码语言:javascript复制module.exports = {
mode: 'development', // development production
// eval-source-map 仅限在开发模式下使用
// 此选项生成的Source Map能够保证“运行时报错的行数”与“源代码的行数”保持一致
devtool: 'eval-source-map',
}
webpack 生产环境下的 Source Map
在生产环境下,如果省略了 devtool
选项,则最终生成的文件中不包含 Source Map。这能够防止原始代码通过 Source Map 的形式暴露给别有所图之人
只定位行数不暴露源码
在生产环境下,如果只想定位报错的具体行数,且不想暴露源码。此时可以将 devtool
的值设置为 nosources-source-map
。
定位行数且暴露源码
在生产环境下,如果想在定位报错行数的同时,展示具体报错的源码。此时可以将 devtool
的值设置为 source-map
。
Source Map 的最佳实践
① 开发环境下:
- 建议把
devtool
的值设置为eval-source-map
- 好处:可以精准定位到具体的错误行
② 生产环境下:
- 建议关闭 Source Map 或将
devtool
的值设置为nosources-source-map
- 好处:防止源码泄露,提高网站的安全性