前端工程化工具（前端 工程化）



前端工程化是根据业务特点，将前端开发流程规范化，标准化，它包括了开发流程，技术选型，代码规范，构建发布等，用于提升前端工程师的开发效率和代码质量。

www.bilibili.com/video/BV1mL…

进入开发需要做的准备

1. 需要有package.json，它是npm依赖管理体系下的基础配置文件
2. 使用npm或Yarn作为包管理器
3. 确定项目技术栈，在明确选择后安装相关依赖包并在src目录中建立入口源码文件
4. 选择构建工具，主流选择是webpack（除非项目已先锋性地考虑尝试 nobundle方案）对应项目里需要增加相关的webpack配置文件，可以考虑针对开发/生产环境使用不同配置文件
5. 打通构建流程，安装与配置各种Loader、插件和其他配置项
6. 优化构建流程，针对开发/生产环境的不同特点进行各自优化
7. 选择和调试辅助工具，例如代码检查工具和单元测试工具，安装相应依赖并调试配置文件
8. 检查各主要环节的脚本是否工作正常，编写说明文档README.md
9. 不需要纳入版本管理的文件目录记入.gitignore等

在软件开发领域，脚手架指通过各种工具来生成项目基础代码的技术。代码中通常包含项目开发流程中所需的工作目录内的通用基础设施。

• 准备好一个项目的基础开发设施，需要投入大量时间和精力
• 较短时间内配置一个技术栈完整、辅助功能丰富、兼顾不同环境下构建优化目标的项目基础代码需要开发人员在工程领域长久的知识储备与实践总结
• 不同的项目需求和团队情况，需要根据不同的现状使用不同的基础设施

• 利用脚手架工具，可以经过几个简单的选项快速生成项目的基础代码
• 用脚手架工具生成的项目模板通常是经过经验丰富的开发者提炼和检验的
• 手架工具支持使用自定义模板，可以根据项目中的实际经验总结、定制一个脚手架模

• 通过技术选型来确定所需要使用的技术栈
• 然后根据技术栈选择合适的脚手架工具，来做项目代码的初始化
• 了解脚手架模板中的技术细节，除了需要学会如何使用脚手架来创建项目还需要了解它提供的具体功能边界，提供了哪些功能、哪些优化

Yeoman

• Yeoman由Google I/O在2012年首发布
• 功能：基于特定生成器（Generator）来创建项目基础代码
• 它提供足够的开放性和自由度
• 但缺乏某一技术栈的深度集成和技术生态
• Yeoman更多用于一些开发流程里特定片段代码的生成

Create-React-App

• Create React App（简CRA）是 Facebook官方供的 React开发工具集
• create-react-app用于选择脚手架创建项目
• react-scripts提供了封装后的项目启动、编译、测试等基础工具
• CRA将一个项目开发运行时的各种配置细节完全封装在一个react-scripts依赖包中，但为后期的用户自定义优化带来了困难

Vue CLI

• VueCLI由Vue.js官方维护，其定位是Vue.js快速开发的完整系统完整的VueCLI由三部分组成：

1. 作为全局命令的@vue/cli
2. 作为项目内集成工具的@vue/cli-service
3. 作为功能插件系统的@vue/cli-plugin-

• VueCLI保留了创建项目开箱即用的优点，提供了用于覆盖修改原有配置的自定义构建配置文件和其他工具配置文件
• Vue CLI提供了通过用户交互自行选择的一些定制化选项，例如是否集成路由、TypeScript等

三者对比：

Yeoman 代表一般开源工具的理念

它专注于实现脚手架生成器的逻辑和提供展示第三方生成器，主要目标群体是生成器的开发者   CRA代表面向某一技术栈降低开发复杂度的理念 它提供一个包含各开发工具的集成工具集和标准化的开发－构建－测试三步流程脚本

Vue CLI代表更灵活折中的理念

继承了CRA降低配置复杂度的优点 在创建项目的过程中提供更多交互式选项来配置技术栈的细节，允许在项目中使用自定义配置

www.bilibili.com/video/BV1Bk…

A：ChatGPT回答：

0. 确定功能和特性： 首先，你需要确定你的脚手架应该具备什么功能和特性。考虑以下问题：

•   你的脚手架是用于创建项目模板还是执行某些任务？
•   需要哪些命令和选项来配置和控制脚手架的行为？

1. 选择开发语言和工具： 选择你熟悉且适合实现脚手架的开发语言，常见的选择有Node.js（JavaScript/TypeScript）、Python等。你还需要考虑用于构建命令行界面的库或框架，比如Node.js下的"yargs"或"commander"，Python下的"click"等。
2. 创建项目结构： 在项目中创建基本的目录结构，包括用于执行命令的入口文件和各种模板或任务相关的文件。
3. 实现核心逻辑： 开始编写核心逻辑，包括解析命令行参数、调用相应的功能函数以及生成项目模板或执行任务等。确保你的代码结构清晰，易于维护。
4. 实现模板生成（可选）： 如果你的脚手架是用于创建项目模板，确保实现一个模板生成的功能。这可能涉及复制文件、根据用户输入进行模板渲染等。
5. 添加辅助功能（可选）： 考虑是否添加辅助功能，如显示帮助信息、版本信息，提供参数验证和错误处理等。
6. 测试： 编写测试用例来确保脚手架的正确功能。测试应该覆盖各种使用情况和边界情况。
7. 发布： 将你的脚手架发布到合适的包管理系统（如npm、PyPI等）上，以便其他人可以通过命令行安装和使用。
8. 文档和示例： 编写详细的文档和示例，介绍脚手架的功能和使用方法。好的文档能够帮助用户快速上手和解决问题。
9. 维护和改进： 持续维护和改进你的脚手架，根据用户反馈和需求来添加新功能和修复bug。

• 热更新是保存后自动编译（Auto Compile）吗？
• 还是自动刷新浏览器（Live Reload）?
• 还是指 HMR（Hot Module Replacement，模块热替换）?
• 这些不同的效果背后的技术原理是什么呢？

在本地开发的同时打开浏览器进行预览，当代码文件发生变化时，浏览器自动更新页面内容的技术。表现上分为：

• 自动刷新整个页面
• 页面整体无刷新而只更新页面的部分内容

• 既依赖 webpack核心代码中 HotModuleReplacementPlugin 所提供的相关 API
• 也依赖在具体模块的加载器中实现相应API的更新替换逻辑
• vue-loader、react-hot-loader等加载器也都实现了该功能

• 编写的源代码会经过多重处理（编译、封装、压缩等），最后形成产物代码。
• source-map的基本原理，在编译处理的过程中在生成产物代码的同时，生成产物代码中被转换的部分与源代码中相应部分的映射关系表。
• 通过 Chrome控制台中的＂Enable Javascript source map＂来实现调试时的显示与定位源代码功能
• 对于同一个源文件，根据不同的目标，可以生成不同效果的source map。在构建速度、质量（反解代码与源代码的接近程度以及调试时行号列号等辅助信息的对应情况）访问方式（在产物文件中或是单独生成sourcemap文件）和文件大小等方面各不相同

• 在开发环境中，通常关注的是构建速度快，质量高，以便于提升开发效率
• 在生产环境中，通常更关注是否需要提供线上 source map，生成的文件大小和访问方式是否会对页面性能造成影响等，其次才是质量和构建速度

便捷性依次降低：

源代码>缺少列信息的源代码>loader转换后的代码>生成后的产物代码>无法显示代码对应对质量产生影响

关键字优先级:

souce-map = eval-source-map > cheap-module-> cheap- > eval = none > nosource-

构建的速度

• 在开发环境下：一直开着devServer，再次构建的速度对效率影响远大于初次构建的速度 eval- 对应的 EvalSourceMapDevToolPlugin 整体要快于不带 eval-的 SourceMapDevToolPlugin
• 在生产环境下：通常不会开启再次构建，初次构建的速度更值得关注

开发环境首选哪一种预设取决于 source map对于我们的帮助程度

• 如果对项目代码了如指掌，可以关闭devtool或使用eval来获得最快构建速
• 如果在调试时，需要通过 source map来快速定位到源代码，优先考虑使用eval-cheap-modulesource-map，它的质量与初次/再次构建速度都属于次优级
• 根据对质量要求更高或是对速度要求更高的不同情况 可以分别考虑使用 eval-source-map或eval-cheap-source-map

• 在程序设计中使用模拟（Mock）的对象来替代真实对象以测试其他对象的行为
• 在前端开发流程中指模拟数据（俗称假数据）以及生成和使用模拟数据的工具与流程

• 前端需要依赖一定的数据模型来组织页面与组件中的交互流程，数据模型依赖着后端提供的API接口
• 假设在后端实际API功能完成之前，能获得对应的模拟数据作为接口的返回值来处理前端交互中的数据模型，待开发完成进入联调后将假数据的部分切换到真实的后端服务接口数据，将大大提高效率

1. 直接在代码中侵入式地书写静态返回数据来调试相关逻辑（应用场景局限）
2. 使用后端开发服务作为Mock服务，将未实现的功能在后端返回Mock数据（前端独立性低）
3. 通过一些本地Mock工具，使用项目本地化的Mock规则文件来生成Mock数据
4. 使用功能更丰富的接口管理工具来提供独立的Mock能力（前期搭建成本高）

1. 仿真度：

• Mock数据需要在接口定义上尽可能与后端实际提供接口的各方面保持一致
• 数据定义的仿真度是决定实际模拟过程效率和质量的首要因素
• 通常在开发初期通过接口文档的方式来提供，或由提供类似功能的Mock工具来提供

2. 易用性：

• 高效的Mock工具需要具备将接口文档自动转换为Mock接口的能力
• 当接口发生变化时会首先更新到文档中，并自动反映到提供的Mock数据中
• 后端提供的真实服务应当完整通过Mock接口的测试

3. 灵活性：

• 实际的接口调用中会根据不同的调用方式与传入参数等条件来输出不同的返回值
• 前端根据不同条件下返回值的差异做不同的交互处理

• 两种工具都需要在项目本地编写数据生成模板或方法
• 根据一定的方式拦截API请求并指向本地生成的Mock数据拦截的方法：

1. 可以类似Mock.js的覆盖API调用对象
2. 通过网络代理将后端域名指向本地目录

1. Mock.js

Mock.js的核心能力是：定义了两类生成模拟数据的规范，以及实现了应用相应规范生成模拟数据的方法

• 数据模板定义规范（Data Template Definition，DTD）
• 数据占位符定义规范（Data Placeholder Definition， DPD）

2. Faker.js

本地 Mock 工具缺点：

• 本地植入模拟数据生成器的方式从整体前后端工作的效率而言，并非最佳选择：

1. 数据模板和TypeScript类型需要通过人工来保持一致，缺乏自动检验的功能（解决方案：基于 TypeScript接口类型描述对象来自动生成模拟数据）
2. 仍然需要后端编写完整的接口文档后才能开始编写数据生成逻辑
3. 本地模拟数据规则本质上和接口文档脱离 （解决方案：将接口文档和Mock数据服务以及接口测试工具结合在一起）

解决方案：YApi、 ApiFox

• 解决了接口定义与Mock数据脱离的问题：

1. 在接口定义阶段，支持后端服务内定义的OPENAPI风格的接口定义数据直接导入生成接口文档也支持在工具界面内填写字段创建，创建时支持设定返回值的Mock描述
2. 在接口定义完成后，即可直接访问工具提供的Mock服务接口供前端调用
3. 在后端接口开发过程中，可通过工具提供的接口调试功能进行开发调试
4. 在接口完成后的任意时间点，支持接口的自动化测试来保证功能与描述的一致性

·react-scripts集成了 sass-loader，vue-cli-service同时支持这三种预处理器

三种CSS的预处理语言都实现了 变量（Variables）、嵌套（Nesting）、混合（Mixins）、运算（Operators） 父选择器引用（Parent Reference）、扩展（Extend）和大量内建函数（Build-in Functions）·Less缺少自定义函数的功能（可以使用Mixins结合Guard实现类似效果）

·Stylus更有利于编写复杂的计算函数 Sass持.scss与.sass两种文件格式 Less的整体语法更接近于.scss Stylus同时支持似.sass的精简语法和普通CSS语法

· Sass 有两种 npm 编译安装包，基于 LibSass的 node-sass和基于 dart-sass的 Sass ·使用webpack构建，三种语言对应的预处理器是 sass-loader、less-loader、stylus-loader 注意：sass-loader和 stylus-loader安装时需要同时安装独立编译包 Sass/node-sass和 Stylussass-loader 处理 partial 文件中的资源路径时需要增加 resolve-url-loader （以及 sass-loader中需要开启sourceMap参数）以避免编译时的报错 stylus-loader 需要增加“resolve url”参数

Pug支持选代（Iteration）、条件（Condition）、扩展（Extend） 包含（Include）、混合（Mixins）等逻辑功能

Vue 文件的 template 支持添加 lang=＂pug＂ 在 vue-cli-service的webpack配置中，内置了 pug-loader作为预处理器在React开发中，通过 babel插件获得支持

使用 IDE （Integrated Development Environment，集成开发环境） 的相关预设功能帮助生成代码 功能主要包括：智能帮助、Snippet和Emmet 在IDE中会默认内置一些智能帮助功能 例如输入时的联想匹配、自动完成、类型提示、语法检查等

代码片段snippet emmet缩写代码块（新手没必要）

如果想要把这些规则分享给团队内的其他成员或自己的其他电脑设备时又该怎么做呢

• 基础环境准备：准备开发环境所需设施，下载安装开发所需各种应用程序，调试各种配置文件，安装必要IDE插件并调试IDE配置项等
• 下载代码：将项目源代码从代码仓库（例如Git Repo）中下载到个人电脑的开发目录下
• 安装项目依赖
• 运行开发服务
• 编码调试
• 执行任务（Lint检查、格式化
• 检查、单元测试等）

将开发环境部署到远程服务器，通过个人电脑的IDE（Integrated Development Environment，集成开发环境），进行远程连接来进行开发的方式

优势：

01由远程的开发服务器来承载项目数据存储和运行计算的需求

02减少了访问设备变更对于项目开发的影响

主要问题：

• 需要申请单独的开发机资源
• 新申请的开发机需要人工进行基础环境的准备工作
• 将开发机单独用于远程开发，资源分配上可能存在资源利用不充分的问题

云开发模式是将开发环境托管，由远程开发服务器变更为云服务个人电脑通过IDE或云服务提供的浏览器界面访问云端工作区进行开发

云开发模式技术要素： webIDE 容器化 对接其他云服务

低代码开发 开发者主要通过图形化用户界面和配置来创建应用软件

低代码开发平台 低代码开发模式的开发者，通过平台的功能和约束来实现专业代码的产出

1 基于 json-schema

• 在特定场景下，例如开发中后台增删改查页面时，大部分前端手动编写的代码是模式化的
• 页面组件结构模板和相应数据模型的代码组织，可以替换为更高效的
• 通过制定用于编写的JSON语法图式 （JSON Schema），以及封装能够渲染对应JSON语法树的运行时工具集，可以提升开发效率，降低开发技术要求JSON语法树描述

2 基于可视化操作平台

解决了基于 json 方式的缺点

·商用的产品，例如Kony、OutSystems、Mendix、 Appian、iVX（国内）等 ·开源类的产品，例如阿里飞冰、百度Amis、贝壳河图、 Vvvebjs、react-visual-editor等

背景： 需求量大且更新频率快的小型项目 项目流程模式基本相同但又具有一定的定制性 非互联网企业缺少技术资源 开发人员成本昂贵

典型应用场景： 企业内部：将一些频率高的常用简易开发流程，固化为无代码开发产品，供运营或其他岗位人员使用

企业外部： 场景类型固定、模板丰富、定制功能多、后端功能少 有免费或收费的无代码平台，将开发工具提供给缺乏技术资源的企业与个人 设计师可以制作自己的设计模板提供给用户

无代码开发的两种不同方向：面向非开发人员的产品与面向准开发人员的产品

• 1996前端语言的诞生：html css js dom ajax
• 2001文件压缩与合并工具诞生：UglifyJS、CSS Sprite、、、
• 2009包管理工具诞生：node npm yarn
• 2012任务式构建工具：Grunt、Gulp（基本组成：核心处理工具、配置文件、常用的任务插件）
• 2009 模块化 commonjs amd umd esmodule

commonjs

服务标识 一个模块即是一个JS文件，代码中自带module指向当前模块对象 自带exports=module.exports，且exports只能是对象，用于添加导出的属性和方法 自带 require方法用于引用其他模块

模块引用 通过引用require（）函数来实现模块的引用，参数可以是相对路径也可以是绝对路径在绝对路径的情况下，会按照 node_modules规则递归查找

模块加载require（）的执行过程是同步的 执行时即进入到被依赖模块的执行上下文中，执行完毕后再执行依赖模块的后续代码

AMD

CommonJS的Modules/1.0规范只能用于服务端，不能用于浏览器端 模块定义 通过 define（id?， dependencies?， factory）函数定义模块id 为模块标识，dependencies为依赖的模块，factory为工厂函数 模块引用 最早需要通过 require（［id］，callback）方式引用 也支持类似 CommonJS的 var a = require（＇a＇）的写法

UMD

UMD本质上是兼容CommonJS与AMD这两种规范的代码语法糖通过判断执行上下文中是否包含 define或 module来包装模块代码适用于需要跨前后端的模块

ES Module

模块定义 通过export关键字导出任意个数的变量 ·通过export default导出，一个模块中只能包含一个 default的导出类型 模块引用 通过import关键字引用其他模块 ·静态引用格式为 import importClause from ModuleSpecifierimport表达式需要写在文件最外层上下文中 ·动态引用的方式是 import（），返回 promise对象

模块化的构建工具：

大业务项目用 webpack 小工具用 rollup

• webpack.js

运行 webpack：根据配置生成编译器实例，根据参数加载不同的插件，根据回调函数执行 watch /run 模式

• compiler.js

readRecords 读取构建记录，用于分包缓存优化，在未设置recordsPath时直接返回

• compilation.js

可以利用 hooks 编写统计插件

Webpack社区中有一些较成熟的统计插件 例如speed-measure-webpack-plugin等

可以根据耗时统计来优化自己的项目编译速度

• 针对某些任务，使用效率更高的工具或配置项，从而提升当前任务的工作效率
• 提升特定任务的优化效果，以减少传递给下一任务的数据量，从而提升后续环节的工作效率

在Compiler和Compilation的各生命周期阶段里通常耗时最长的分别是哪个阶段呢 对于 Compiler 实例 耗时最长的是生成编译过程实例后的make阶段 对于 Compilation 实例 编译模块和后续优化阶段的生成产物并压缩代码的过程都比较耗时

准备基于时间的分析工具 例如speed-measure-webpack-plugin 准备基于产物内容的分析工具 使用 webpack-bundle-analyzer分析产物内容，来减少冗余的依赖包

1.减少执行编译的模块数量

• 使用 IgnorePlugin：比如其他语言包moment
• 按需引入：比如lodash只用到了其中几个方法
• DllPlugin
• Externals

2.在保持构建模块数量不变的情况下，提升单个模块构建的速度

• include/exclude， 因为有的 loader 速度慢不如 webpack 默认的
• noParse，在include/exclude基础上进一步省略了使用默认编译器的编译时间
• Source Map
  • 对于生产环境的代码构建而言，会根据项目实际情况判断是否开启Source Map
  • 在开启Source Map的情况下，优先选择与源文件分离的类型
  • 有条件也可以配合错误监控系统，将SourceMap的构建和使用在线下监控后台中进行
• TS编译优化
  • 由于ts-loader默认在编译前进行类型检查，因此编译时间往往比较慢
  • 通过加上配置项transpileOnly:true，可以在编译时忽略类型检查
  • babel-loader 需要单独安装 @babel/preset-typescript来支持编译 TS
• Resolve配置（小项目影响不大）

3.使用并行构建工具提升总体效率（大项目使用）

HappyPack与 thread-loader

parallel-webpack

js 压缩：terser、uglifyjs

css 压缩

• OptimizeCSSAssetsPlugin(在 Create-React-App中使用)
• OptimizeCSSNanoPlugin(在VUE-CLI中使用)
• CSSMinimizerWebpackPlugin(2020年Webpack社区新发布的CSS压缩插件)（支持缓存和多进程）

分包

Split Chunks（分包）是指在 Chunk生成之后将原先以入口点来划分的Chunks根据一定的规则分离出子Chunk的过程

tree shaking

"Tree shaking"是一个与 JavaScript 模块打包和优化相关的概念。它指的是一种在构建过程中剔除未被使用的代码的优化技术，以减小最终生成的代码包的大小。这个术语通常与模块打包工具（例如Webpack、Rollup等）和 ES6 模块化语法相关联。

触发条件：

1.es6

• 只有ES6类型的模块才能进行Tree Shaking
• CommonJS类型的模块lodash，需要依赖第三方提供的插件才能实现动态删除无效代码
• ES6风格的模块 lodash-es，则可以进行 Tree Shaking优化

2.引入方式

• 以 default 方式引入的模块，无法被 Tree Shaking
• 引入单个导出对象的方式，使用import＊as xxx的语法，还是import ｛xxx｝的语法

3. sideEffects

• 在Webpack 4中，会根据依赖模块 package.json 中的 sideEffects属性来确认对应的依赖包代码是否会产生副作用
• rule.sideEffects（默认为 false）指代在要处理的模块中是否有副作用
• optimization.sideEffects（默认为true）指代在优化过程中是否遵循依赖模块的副作用描述

4. babel

• 在Babel 7之前的babel-preset-env中， modules的默认选项为 'commonjs'
• 在Babel 7之后的@babel/preset-env中， modules选项默认为 'auto'

webpack 默认开启了缓存

babel-loader开启缓存选项

将 cache-loader 添加到对构建影响较大的 loader 之前

• 生成ChunkAsset时的缓存优化

在Webpack4中，生成ChunkAsset过程中的缓存优化是受限制的 只有在watch模式下，且配置中开启cache时（development模式下自动开启）才能在这一阶段执行缓存的逻辑

• 代码压缩时的缓存优化
  • 对于JS的压缩，TerserWebpackPlugin 和 UglifyJSPlugin 都是支持缓存设置的
  • 对于CSS的压缩，目前最新发布的CSSMinimizerWebpackPlugin支持且默认开启缓存。其他的插件如OptimizeCSSAssets、PluginOptimize、CSSNanoPlugin目前还不支持使用缓存

1.缓存失效：

如何最大程度地让缓存命中成为我们选择缓存方案后首先要考虑的事情

• 减少缓存标识符变动

支持缓存的Loader和插件中会根据一些固定字段的值加上所处理的模块或Chunk的数据hash值来生成对应缓存的标识符。 例如特定依赖包的版本、对应插件的配置项信息、环境变量等。

注意：在许多项目的集成构建环境中，特定依赖包由于安装时所生成的语义化版本导致构建版本时常自动更新，并造成缓存失效

• 编译阶段不太有缓存失效问题
• 打包阶段缓存失效

尽可能地把那些不变的处理成本高昂的模块打入单独的Chunk中

使用splitChunks优化缓存利用率

2.CI/CD中的缓存目录问题

在许多自动化集成的系统中，项目的构建空间会在每次构建执行完毕后，立即回收清理在集成化的平台中构建部署的项目，如果需要使用缓存

需要根据对应平台的规范，将缓存设置到公共缓存目录下

3.缓存的清理

缓存的便利性本质在于用磁盘空间换取构建时间

对于一个大量使用缓存的项目，随着时间的流逝，缓存空间会不断增大对于上述多项目的集成环境而言，则需要考虑对缓存区域的定期清理

4.与产物的持久化缓存相区别

浏览器端加载资源的缓存问题

以及相对应的如何在Webpack中生成产物的持久化缓存方法（hash、chunkhash、contenthash）这一部分知识所影响的是项目访问的性能，而对构建的效率没有影响

几种支持缓存的插件（TerserWebpackPlugin，CSSMinimizerWebpackPlugin） 和Loader（babel-loader，cache-loader）在缓存方面有哪些相同的配置项呢

01用于指定是否开启缓存以及指定缓存目录

02用于指定缓存标识符的计算参数

为什么我只改了一行代码，却需要花5分钟才能构建完成？ 尽管只改动了一行代码，但是在执行构建时要完整执行所有模块的编译、优化和生成产物的处理过程

在开启devServer的时候 执行webpack-dev-server命令后，Webpack会进行一次初始化的构建 构建完成后启动服务并进入到等待更新的状态

增量构建之所以快是因为将构建所需的数据都保留在内存中 对于管理多项目的构建系统，构建过程是任务式的：任务结束后即结束进程并回收系统资源要想在生产环境下提升构建速度，首要条件是将缓存写入到文件系统中（webpack4 没提供文件系统的缓存）

Persistent Caching——持久化缓存 buildDependencies version name tree shaking logs 其他

无包构建：只编译不打包，交给浏览器来分析依赖

无包构建产生的基础是浏览器对JS模块加载的支持

• 对 html 文件的预处理
• 对外部依赖包的解析
• 对 vue 文件的解析
• 对 css 文件的解析

vite其他辅助功能

• 多框架

支持在React和Preact项目中使用。工具默认提供了Vue、React和Preact对应的脚手架

• 模板热更新（HMR）

默认的3种框架的脚手架模板中都内置了HMR功能，也提供了HMR的API供第三方插件或项目代码使用

• 自定义配置文件

支持使用自定义配置文件来细化构建配置，配置项功能参考config.ts

• HTTPS与HTTP/2

支持使用－https启动参数来开启使用HTTPS和HTTP/2协议的开发服务器

• 服务代理

在自定义配置中支持配置代理，将部分请求代理到第三方服务

• 模式与环境变量

支持通过 mode 来指定构建模式为 development 或 production

相应模式下自动读取 dotenv类型的环境变量配置文件

• 生产环境打包

生产环境使用Rollup进行打包，支持传入自定义配置，配置项功能参考build/index.ts

vite 使用限制

• 面向支持ES6的现代浏览器，在生产环境下，编译目标参数 esBuildTarget的默认值为es2019，最低支持版本为es2015
• 对Vue框架的支持目前仅限于最新的Vue3版本，不兼容更低版本

相同点 Snowpack与 Vite两者都支持 各种代码转换加载器、热更新、环境变量（需要安装dotenv插件）、服务代理、HTTPS与HTTP/2等

不同点 相同的功能，实现细节不同Vite支持类似＂AAA/BBB＂类型的子模块引用方式 而Snowpack目前尚不支持

工具稳定性 Vite最版为v1.0.0-rc4 Snowpack更到了v2.11.1版

插件体系 Snowpack提供了较完善的插件体系，Vite目前并没有提供自定义插件的相关文档

打包工具 Vite使用Rollup作为打包工具Snowpack需要引入插件实现打包功能

特殊优化 Vite中内置了对Vue的大量构建优化

1. 初次构建启动快
2. 按需编译
3. 增量构建快

1. 将每一个模块都生产请求，浏览器网络请求数量剧增，开发环境还行，生产环境灾难
2. 浏览器兼容性

前端项目的一般部署流程： 获取代码 安装依赖 源码构建 产物打包 推送代码 重启服务

为什么要使用部署系统而不是在本地环境下部署代码？ 本地部署的优势（速度快）： 代码版本处理、安装依赖都更快、可以把构建进程保留在内存中实现增量构建、快速调试

部署系统的优势（安全规范）： 流程安全风险低：环境一致性、流程一致性 工作效率：可回溯性（日志、产物）、人员分工（不用每个人都部署）、CI/CD

CI/CD 持续集成（Continuous Integration，CI) 持续交付（Continuous Delivery,CD)

开发人员提交代码后，由CI/CD系统自动化地执行合并、构建、测试和部署等一系列管道化（Pipeline）的流程，从而尽早发现和反馈代码问题，以小步快跑的方式加速软件的版本迭代过程

优秀的部署系统的特点： 自动化地完整部署流程的各环节，能保证环境与过程的一致性，增强流程的稳定性，降低外部因素导致的风险 提供过程日志、历史版本构建包、通知邮件等各类辅助功能模块，来打造 更完善的部署工作流程

Jenkins（本地化、免费）

搭建方式

基于Java的应用程序，支持分布式的服务方式，各任务可以在不同的节点服务器上运行

多类型Job

自定义项目、流水线、文件夹、多配置项目、Github组织等

插件系统

Jenkins架构中内置的插件系统为它提供了极强的功能扩展性

收费方式

完全免费的开源产品

API调用

Jenkins提供了 Restful的 API接口 可用于外部调用控制节点、任务、配置、构建等处理过程

CircleCI（云/本、部分免费）

Github Actions

Github Actions（GHA）是Github官方提供的CI/CD流程工具用于为Github中的开源项目提供简单易用的持续集成工作流能力

功能特点

多系统 提供Linux、Mac、Windows等各主流操作系统环境下的行能力，同时也支持在容器中运行矩阵运行 支持同时在多个操作系统或不同环境下运行构建和测试流程 多语言 支持NodeJS、JAVA、PHP、Python、Go、Rust等各种编程语言的工作流程 多容器测试 支持直接使用Docker-Compose进行多容器关联的测试（CircleCl中需要先执行安装才能使用） 社区支持 Github社区中提供众多工作流的模板可供选择，例如构建并发布npm包、构建并提交到Docker Hub等费用情况 对于公开的仓库，以及在自运维执行器的情况下是免费的 对于私有仓库则提供一定额度的免费执行时间和免费存储空间，超出部分需要收费

Gitlab CI

Gitlab是由 Gitlab Inc.开发的基于 Git的版本管理与软件开发平台 具有在线编辑、Wiki、CI/CD等功能 提供了免费的社区版本（CommunityEdition，CE）和免费或收费的商用版本（Enterprise Edition，EE）

GitlabCI使用yml文件作为CI/CD工作流程的配置文件 默认的配置文件名为.gitlab-ci.yml 在配置文件中涵盖了任务流水线（Pipeline）的处理过程细节： 例如在配置文件中可以定义一到多个任务（Job） 每个任务可以指定一个任务运行的阶段（Stage）和一到多个执行脚本（Script）等

Gitlab中需要单独安装执行器 Gitlab Runner的作用是执行任务，并将结果反馈到Gitlab中开发者在独立的服务器上安装Gitlab Runner工具 然后依次执行 gitlab-runner register注册特定配置的 Runner最后执行gitlab-runner start启动相应服务

总结

如果你所在的企业需要选择一款CI/CD工具，你选择的主要依据有哪些呢？

• 选择付费系统还是免费系统，选择云服务还是自运维
• 所选的方案是否便于对接上下游系统流程
• 使用配置是否便捷，对用户而言是否有学习成本

• npm
• yarn / yarn with PnP / yarn v2
• pnpm

1. 解析依赖关系阶段：分析项目中各依赖包的依赖关系和版本信息
2. 下载阶段：这个阶段的主要功能是下载依赖包
3. 链接阶段：处理项目依赖目录和缓存之间的硬链接和符号连接

使用系统提供的time命令获取执行时间：

• time npm i
• time yarn
• time pnpm i

项目的依赖安装过程，效率最高的3个条件：存在Lock文件存在，存在本地缓存存在和存在安装记录·Lock文件的留存是最容易做到的，也是最可能被忽略的，大部分项目都会保留在代码仓库中 ·本地缓存是当安装记录不存在时最重要的优化手段。对于大部分部署系统，注意磁盘空间与效率的平衡在部署服务的个别项目中，执行清除缓存的操作也会影响其他项目 ·本地安装记录对于部署系统需要占据较多的磁盘空间，建议确认所使用的部署系统是否支持相关设定·安装条件方面，有一些额外的不容易量化的条件，例如网速、磁盘1/0速度等

单从效率而言，各工具在不同安装条件下的优劣各有不同 ·如果考虑各种场景下的综合表现，pnpm是最稳定高效的 ·如果考虑现实情况中，Yarnv1是更好的选择 ·如果考虑只有Lock文件的情况，则npm的表现要优于 Yarn ·在无安装目录的情况下，Yarnv1的PnP模式效率要高于普通模式·Yarnv2支持针对单个项目清除缓存而不影响全局

·Yarn v1普通模式可以作为npm的直接替代，不对构建产生影响·PnP模式、Yarnv2和pnpm在项目中选择工具时需要综合考虑

依赖安装阶段： 提升依赖下载速度： 设置下载源（registry），如淘宝源、二进制下载源

多项目共用依赖缓存，默认

安装目录缓存

代码构建阶段： CI 系统中的持久化缓存

到此这篇前端工程化工具（前端 工程化）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/qdkf/78826.html