工程化工具发展
npm 问题
Npm 最初的设计是直接将依赖平铺在 node_modules 下, 这样在真实场景下，就会产生很多冗余的包，很快就占满磁盘，被称为依赖地狱。
Npm3 为了优化依赖地狱的问题，将子依赖提升, 采用了扁平化的数据结构，子依赖会尽量平铺安装在主依赖所在的目录中。
这样虽然避免了大量包的重复安装和依赖层级过深的问题，但也带来了依赖幽灵的问题。幽灵依赖是指在 package. Json 中未定义的依赖，但项目中依然可以正确地被引用到。
另外，还会有类似同样的 package. Json 文件，install 依赖后可能不会得到同样的 node_modules 目录结构。 依赖结构的不确定性和依赖分身这样的问题。
这是就需要 Yarn 带来创新
tnpm 和 cnpm 是什么？
简单的说：
- cnpm 是我们开源的 npm 实现，支持官方 npm registry 的镜像同步，以及私有包能力。
- npmmirror 是社区基于 cnpm 部署的一个公益项目，为中国前端开发者提供镜像服务。
- tnpm 是我们在阿里巴巴及蚂蚁集团的企业服务，同样基于 cnpm 之上做了企业级的能力定制。
任务式构建工具
任务式构建工具发展历程回顾：
2012 年，Ben Alman 发布了基于任务的构建工具 Grunt。
2013 年，Eric Schoffstall 发布了流式的构建工具 Gulp。
Grunt vs Gulp
这两种工具的差异性主要体现在：
- **读写速度：**Gulp 在处理任务的过程中基于 NodeJS 的数据流，本质上是操读写内存，而 Grunt 则是基于临时文件，因此在读写速度上 Gulp 要快于 Grunt。
- **社区使用规模：**截止编写课程的时间点，在 npmjs.com 的周下载量方面，Gulp 为 1,200,000+，约是 Grunt 的两倍。而在插件数量方面，Grunt 社区提供了超过 6000 个不同功能的插件，而 Gulp 社区的插件数量则是 4000 多个。
- **配置文件的易用性：**相比描述不同插件配置信息的 Gruntfile 而言，使用 pipe 函数描述任务处理过程的方式通常更易于阅读，但编写时需要对数据流有更深入的理解。
任务式的构建工具，虽然解决了开发流程中自动化执行预设任务的问题，但不能解决项目中代码如何组织成不同功能的代码包、不同代码之间如何相互依赖等问题。而解决这类问题的方式就是：模块化。