前端模块打包器的开发实践1：需求分析
发布时间：2020/5/25 13:18:38
前端模块化现状
分类：以Webpack，browserify的静态分析 VS RequireJS amd模块
（es6 的模块我认为还是一种语法糖而已，在前端浏览器的支持还长时间地需要转换器的转换）
静态分析以使用CommonJS方式组织代码，指定入口文件，默认将所依赖的代码合并到同一个文件中去，文件发送请求少。而且有一个最重要的好处就是Webpack自带的Code Splitting 代码分割可以允许开发者将不同的代码组织在一起，符合前端组件化的需求。
amd模块的模块编写方式是遵守amd规范的，然后通过loader（加载器）将模块按需加载。模块是分散的。
（这里讨论问题时候只着眼于重点）
不足就是相互的优点：
静态分析的Webpack ， 在按需加载的实现颇为麻烦，甚至有一点不可行
amd模块的编写，文件请求次数多，只有单次依赖的模块需要发起单独请求。文件组织形式（由于amd模块没有考虑Css模块，Html模块的加载，在如今前端组件化组织的前景下逐渐没意义了）唯一是Js.
需求分析
代码分割，优点就是能够将Html Css Js 组织在同一个文件之中。
代码局部作用域
（上述都是组件化的需要）
模块及依赖打包（模块粒度的控制）
模块的层级：
全局
局部
私有
全局一般是外部库， 自己写的公有库；局部是在某几个组件都使用的库 ；私有：只是用一次的库
最近很多人都在使用SPA的开发方式，但是，SPA+Router不就是MPA吗？
由于将模块层次分割出来，这就有了中间层（局部）模块的按需加载需求了
正因为按需加载，所以有必要使用规范的模块格式
模块及依赖的识别，以及生成模块树
综上所述，我们形象地说希望构建Webpack+RequireJS的一个工具
