4.1 依赖管理工具
模块化方案：
- AMD
- CommonJS
- UMD
现在主流的前端应用框架支持并采用的方式主要以编译构建为主，大都采用NPM+CommonJS的形式来管理依赖。
4.2 软件包源管理
软件包源有以下几种形式：
- 公有/私有软件包源服务器。
- npmj.org提供的官方源。
- 淘宝的cnpm源。可用于搭建自己的私有化包服务器。
- 搭建私有的NPM服务器。
- 基于源码版本管理服务器，比如直接使用Git服务器来管理和分布库的版本。
- 本地的软件包，使用相对路径导入本地仓库。
1.基于源码版本管理服务器
对于一些内部的前端库，除了自己搭建NPM服务器，还可以通过Git服务器及Git Tag的方式进行管理。
即在package.json中通过
"adr":"git+http://github.com/xmwarrior/adr/#v1.0.0"
的方式引入依赖。
这种方式需要将构建完的源码提交到代码库。此种方式会让代码库因版本的增多而愈发臃肿。
2. 本地的软件依赖包
通过包管理工具来支持file协议并引入依赖，即在package.json中通过"adr":"file:adr"的形式引入依赖。
这种方式的应用场景如下：
- 构建的包过大，不适合Git下载。
- 开发应用的同时开发依赖。
3.前端应用的编译
不论如何开发，最终需要打包成HTML+CSS+JavaScript的形式。
4. JavaScript的编译
ES6、Typescript
5. CSS的编译
CSS预处理器
6. CSS In JavaScript
CSS的继承与覆盖特性，促成了CSS In JavaScript的诞生。
7. 模板编译
前端框架，间接的通过js代码生成HTML DOM节点，来提高运行效率。
4.3 前端代码的打包
代码打包的最后一步就是，将代码“拼接”到一起，压缩并混淆代码，最后构建出目标代码文件。
期间，还会进行可选的摇树优化（Tree Shaking，去掉没用的代码），其主要依赖于ES6模板及其带来的静态分析。
4.4 设计构建流
1. 如何设计构建流
- 任务。通用流程、任务。命令一致，拆解背后对应的细节、任务。
- 步骤拆解。命令一方面受前端框架的影响，另一方面受项目的复杂度影响。
- 展现形式。不同类型的构建应用，展现形式有所不同。
- 插件。当且仅当有多个插件时，我们才能打造更流畅的构建流。
构建工具的选择，可以是Grunt、Gulp、webpack等中的一个，或者直接用NPM来完成。这些工具没有太大的区别，要做的事情的复杂性决定了使用的工具。
2. 构建工具：自动化任务
构建工具相当于是一个自动化任务工具，也可以称之为任务管理器。
不同构建工具的适用场景：
- NPM脚本，适用于脚本简单的应用构建。
- Gulp/Grunt，适用于复杂的项目工作流构建。
- webpack，进行项目的模块化打包。
3. 使用包管理工具构建NPM
通过在package.json的script部分添加多个任务，进行简单的构建。
此种方式会随项目的复杂度提升，任务命令越来越长，使命令本身的可读性越来越差。
使用JSON文件来管理任务，另一方面因其本身不能编写注释，也使任务很难文档化。
此时可以考虑使用脚本文件的形式来管理。如node build.js。还有一种更实用的方式，结合NPM脚本与webpack或Gulp/Grunt使用，如
"build":"webpack --config webpack.dist.config.js"
4. 使用构建工具构建Grunt/Gulp
对于复杂的构建流，可以考虑Gulp/Grunt来完成构建。
编程的方式比配置的方式更能提高可管理性。这也是Gulp/Grunt越来越流行的原因。
5. 使用打包工具构建webpack
本质上，webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。
当前的主流框架都是用webpack来打包应用，除了承担打包工作，它还负责一部分常见的构建任务。对于前端框架来说，他们更倾向于屏蔽这些webpack的复杂的配置。
6. 实现构建流
尽管应用的构建很重要，但是编写前端应用的时候，我们往往不会自己从头去编写构建代码。第一，它需要花费大量的时间。第二，现成的构建代码可以使用。
7. 插件定义构建流
总有一些特殊情况，需要我们在构建脚本里添加命令。这时，尝试通过以下方式来解决问题。
- 查找是否有对应的插件。
- 对比不同插件的区别。
- 创建插件的适配层。
- 验证插件是否有效。
- 重复2~4步骤。
- 如果都不适用，编写新插件或改写原有插件。
8. 框架定义构建流
流行的前端框架提供了完整的应用脚手架，脚手架中也提供了完整的构建流。
只有当应用和架构变得复杂时，我们才需要去了解它是如何构建的，才需要去修改构建脚本。
4.5 持续交付问题
1. 部署方式
- 持续部署，构建完成及部署，类似GItHub Pages，提交代码后自动上线。
- 自动化部署，持续部署的前提下稍微弱化，需人为的介入。
- 手动部署，全程人为操作。
部署都需要一个确定的发布策略——不论是敏捷模式还是瀑布模式。
敏捷模式的上线发布计划是一个分布迭代（通常两周一次），随后不断地发布；
瀑布模式则是一次上线就完成大部分主要功能。
2. 设计持续集成
- 对应用进行构建。
- 进行应用的测试，利用代码来完成测试有助于减少bug。
- 部署应用到对应的环境，以提供一个联调和测试环境。
- 选择合适的持续集成工具：开源的Jenkins、GoCD；专业的收费工具Bamboo。
- 编写相应的部署脚本。
3. 自动化部署
前端的自动化部署：
- 静态文件部署到服务器上后，使用Nginx配置域名及相应的后台服务地址。
- 然后搭配Docker，编写Dockerfile就能快速的应用部署。
- 再编写一个相应的NPM脚本，配置到Jenkinsfile中，就完成了整个持续部署的的流程。
还有Puppet、Chef等部署工具。
尽管前端部署简单，还应适当考虑“回滚机制、蓝绿部署、灰度发布”等因素。并在应用部署后，使用UI自动化测试来测试部分功，以及测试对应的后端服务连接。这里不推荐人工测试。
4. 环境配置
不同的环境拥有不同的功能、代码及配置事项。当我们编写构建脚本的时候，还需要针对不同的环境（开发、线上）编写构建脚本。
5. 开发环境配置
需要考虑：
- 构建配置。构建脚本时，考虑额外的配置与参数来针对不同的环境。
- 代码配置。通过不同的环境变量来区分不同环境。如.env.development
- 代理配置。
6. 线上调试
为了线上运行和调试代码，通常需要有一些额外的“开关”（toggle），如：
- 在URL中添加一些参数。
- 在LocalStorage中添加一些参数。
- 对特定的账号进行权限管理，以获取调试功能。
《前端架构：从入门到微前端》——知识点整理。
