虽然 Webpack 看上去无所不能，但从其本质上来说，Webpack 实质就是一个“前端模块打包器”。前端模块打包器做的事情很简单：它帮助开发者将 JavaScript 模块（各种类型的模块化规范）打包为一个或多个 JavaScript 脚本文件。
回到最初起源：前端为什么需要一个模块打包器呢？其实理由很简单：
- 不是所有浏览器都直接支持javascript
- 前端需要管理依赖脚本，把控不同脚本加载的顺序
- 前端需要按需加载不同类型的静态资源
工程化思维处理方案：如何实现应用主题切换功能
代码拆分和按需加载
制定一个统一标准化babel-preset
首先我们要认清应用项目构建和公共构建的差别。作为前端团队，我们构建了很多应用项目，对于一个项目来说，“只要能在需要兼容的环境中跑起来”就达到了基本目的。而对于一个公共库来说，我们的公共库可能被各种环境所引用或需要支持各种兼容需求，因此公共库就要兼容性能和易用性，要注重质量和广泛度。由此看来，公共库理论上构建机制就更加复杂
制定一个企业级公共库的设计原则
这里说的企业级公共库主要是指在企业内复用的公共库，它可以被发布到npm上进行社区共享。也可以在企业内的私有npm中限定范围地共享。总之，企业级公共库是需要在业务中被使用的。一个企业级公共库的设计原则应该包括一下几点。
- 最快地搭建调试和开发环境
- 安全地发版维护
- 公共库文档建设完善
- 公共库质量有保证
- 接入和使用负担最小
core-js及垫片理念
core-js是一个javascript标准库，它包含了ECMAScript 2020 在内的多项特性的polyfills，以及ECMAScript在proposals阶段的特性、WHATWG/W3C新特性等。因此它是一个现代化前端项目的 “标准套件”
除了core-js本身的重要性，它的实现理念、设计方式都值得我们学习。事实上，core-js是一扇大门：
- 通过core-js，我们可以窥见前端工程化的方方面面
- core-js又和babel深度绑定，因此学习core-js，也能帮助开发者更好地理解babel生态，进而加深对前端生态的理解
- 通过对core-js的解析，我们正好可以梳理前端一个极具特色的概念-polyfill
Yarn的安装理念
当npm还处在v3阶段时，一个叫做Yarn的包管理方案横空出世。2016年，npm 还没有 package-lock.json 文件，安装速度很慢，稳定性也较差，而 Yarn 的理念很好地解决了以下问题。
- 确定性：通过yarn.lock等机制，保证了确定性。即不管安装顺序如何，相同的以来关系在任何机器和环境下，都可以以相同的方式被安装（在npm5之前，没有package-lock.json机制，只有默认并不会使用的npm=shrinkwrap.json）
- 采用模块扁平安装模式：将依赖包的不同版本，按照一定策略，归结为单个版本，以避免创建多个副本造成冗余
- 网络性能更好：Yarn采用了请求排队的理念，类似并发连接池，能够更好地利用网络资源；同时引入了更好的安装失败时的重试机制
- 采用缓存机制，实现了离线模式(npm目前也有类似实现)
npm安装机制
npm 的安装机制非常值得探究。Ruby 的 Gem、Python 的 pip 都是全局安装，但是 npm 的安装机制秉承了不同的设计哲学。
它会优先安装依赖包到当前项目目录，使得不同应用项目的依赖各成体系，同时还减轻了包作者的 API 兼容性压力，但这样做的缺陷也很明显：如果我们的项目 A 和项目 B，都依赖了相同的公共库 C，那么公共库 C 一般都会在项目 A 和项目 B 中，各被安装一次。这就说明，同一个依赖包可能在我们的电脑上进行多次安装