工程化介绍
定义
“工程化” 不是指某个具体的工具,而是一套解决问题的思想。
它主要关注于解决软件开发各环节中存在的效率和质量问题。
典型的效率和质量问题:
-
为兼容老平台而不得不使用老的开发技术
-
存在许多重复手工操作(如编译打包、刷新界面看效果、运行测试、上传部署等)
-
团队开发人员的代码风格五花八门
-
前端等后端给接口@
-
......等等
诸如以上这些问题,都会造成开发效率、及产品质量的低下,最终导致开发成本的上升。
做法
凡是能提高效率、降低成本、保证质量的手段,都属于工程化范畴!比如:
-
通过制定规章制度、操作流程
-
目前最流行的工程化思路: 将一切具有重复性的工作都自动化!
前端工程化介绍
工程化的思想同时适用于前端和后端,因此 “前端工程化” 其实就是工程化思想在前端开发中的运用。
一切能 提升前端的开发、测试、部署效率的方法,都属于前端工程化的范畴。
前端开发各阶段中,可通过工程化改进的点:
前端工程化实施前后的改变:
实施前 | 实施后 |
---|---|
花费较多时间纯手工搭建新项目 | 一条命令即可创建新项目 |
为浏览器兼容性考虑而使用老版本 JS 语法 | 尽情享受最新版 JS 的语法特性 |
在 HTML 中使用 <link> 、<script> 引用 css、js 文件;没有模块机制、或只有简陋的模块机制,一不小心就会出现冲突 | 使用 js、css 模块化机制,不用担心代码冲突问题 |
每次改完代码都要手动刷新页面来查看最新效果 | 改完代码即刻能在多种浏览器上看到最新效果 |
不同开发人员编写的代码风格迥异 | 通过代码检查工具来统一代码格式,降低潜在问题、提高代码质量 |
代码发布时不做文件合并和压缩等优化 | 根据不同环境进行打包、压缩优化、添加文件版本、并生成协助调试的 SourceMaps |
以上只是冰山一角,工程化能带来的好处,其实远比这些更多。
前端工程化工具
了解前端实现工程化时的主要工作,以及完成这些工作所依赖的软件工具
在前端的工程化工作中,其中一个重要工作,就是对项目中的各种文件资源进行自动转换处理。
该工作可借助市面上的相关工具来完成:
热门工具 Gulp 和 Webpack 简介
Gulp
-
自身定位:任务执行器,聚焦于“任务”的执行
-
使用风格:编程式(以编写 js 代码的方式,描述出流水线式的任务执行流程)
-
具备优点:控制力强、使用灵活
const { series, parallel } = require('gulp');
//series串行任务 parallel并行任务
// 任务:清理文件
function clean(cb) {
cb();
}
// 任务:处理 less/sass 文件
function cssTranspile(cb) {
cb();
}
// 任务:压缩 css
function cssMinify(cb) {
cb();
}
// 任务:es6 转 es5
function jsTranspile(cb) {
cb();
}
// 任务:js 合并
function jsBundle(cb) {
cb();
}
//任务:js 压缩
function jsMinify(cb) {
cb();
}
// 任务:代码发布
function publish(cb) {
cb();
}
// 执行顺序 按照先后顺序执行 series串行执行
exports.build = series(
// 1. 先执行 clean
clean,
// 2. 再并行执行 css 和 js 的转换处理
parallel( // css转化和js转换、合并同步进行 parallel并行任务
cssTranspile,
series(jsTranspile, jsBundle)
),
// 3. 在并行执行 css 和 js 的压缩处理
parallel(cssMinify, jsMinify),
// 4. 最后执行发布
publish
);
Webpack
-
自身定位:资源打包器,聚焦于对“资源”的转换处理(即将一种文件变为另一种文件)
-
使用风格:声明式(以编写 js 对象的形式来描述对某种资源的处理方法)
-
具备优点:使用简洁方便、社区庞大、插件众多
const path = require('path')
const MiniCssExtractPlugin = require("mini-css-extract-plugin")
module.exports = {
// 环境模式:开发环境
mode: 'development',
// 入口配置
entry: './src/index.js',
// 输出配置 打包后的结果目录
output: {
path: path.resolve(__dirname, 'dist'), //打包后生成的结果目录dist
filename: 'bundle.js' //打包后生成的目标文件名
},
// 模块处理配置
module: {
rules: [
// 处理 css 和 less 文件
{
test: /\.(css|less)$/,
use: [MiniCssExtractPlugin.loader, 'css-loader', 'less-loader']
},
// 处理静态文件
{
test: /\.(png|jpe?g|gif|svg|eot|ttf|woff|woff2)$/i,
type: "asset", //aset是webpack内置的处理器
},
// 处理 js 文件
{
test: /\.m?js$/,
exclude: /(node_modules|bower_components)/,
use: {
loader: 'babel-loader',
options: {
presets: ['@babel/preset-env'],
plugins: ['@babel/plugin-transform-runtime']
}
}
}
]
},
// 插件
plugins: [
// 压缩 css
new MiniCssExtractPlugin()
]
}
Webpack 进阶介绍
进一步了解目前用于前端工程化的最热门工具:webpack
官方对 webpack 的定位是: 模块打包器(module bundler),它将项目中依赖的各种文件视作 “模块” 来进行打包处理。
该打包处理工作主要涉及:
-
创建、删除文件
-
复制、移动文件
-
修改、转换文件(是 webpack 的核心功能)
当然,webpack 也可用于非文件处理性质的任务。
webpack 进行文件转换是怎么样的一个过程?
-
读取原文件的内容
-
将读取的内容组织成 js 形式的 “webpack 模块”,并记录模块间的依赖关系
-
对 “webpack 模块” 的内容做进一步加工处理
-
对加工后的内容封装定型,封装后就不再允许修改
-
输出这些内容到目标文件(chunk)
webpack 依靠什么完成这些文件处理工作?
两帮兄弟:资源加载器(loader)、插件(plugin)。
1.资源加载器
负责对文件内容进行转换、加工处理。
要点:webpack 默认只认识 js、json 文件,其他格式的文件,一律都需要资源加载器来进行识别和处理。
场景举例:
-
LESS 转 CSS
-
ES6 转 ES5
2.插件
负责监听打包的过程,一旦到达某个环节,就会触发特定事件(即生命周期),执行指定的处理逻辑。
场景举例:
-
在执行打包前,先删除上一次打包所生成的文件
-
在打包完成后,将所有文件都上传到某台服务器
3.每个文件都可经由一个或多个 loader 和 plugin 的处理
每个 loader 和 plugin 的功能都保持单一,保证它们的可复用性,当要完成复杂处理时可组合使用。