前端模块打包器的开发实践1：需求分析

前端模块化现状

分类：以Webpack，browserify的静态分析 VS RequireJS amd模块

（es6 的模块我认为还是一种语法糖而已，在前端浏览器的支持还长时间地需要转换器的转换）

静态分析以使用CommonJS方式组织代码，指定入口文件，默认将所依赖的代码合并到同一个文件中去，文件发送请求少。而且有一个最重要的好处就是Webpack自带的Code Splitting 代码分割可以允许开发者将不同的代码组织在一起，符合前端组件化的需求。

amd模块的模块编写方式是遵守amd规范的，然后通过loader（加载器）将模块按需加载。模块是分散的。

（这里讨论问题时候只着眼于重点）

不足就是相互的优点：

静态分析的Webpack ， 在按需加载的实现颇为麻烦，甚至有一点不可行

amd模块的编写，文件请求次数多，只有单次依赖的模块需要发起单独请求。文件组织形式（由于amd模块没有考虑Css模块，Html模块的加载，在如今前端组件化组织的前景下逐渐没意义了）唯一是Js.

需求分析

1. 代码分割，优点就是能够将Html Css Js 组织在同一个文件之中。

2. 代码局部作用域

   （上述都是组件化的需要）

3. 模块及依赖打包（模块粒度的控制）

   模块的层级：

• 全局

• 局部

• 私有

全局一般是外部库， 自己写的公有库；局部是在某几个组件都使用的库 ；私有：只是用一次的库

最近很多人都在使用SPA的开发方式，但是，SPA+Router不就是MPA吗？

4. 由于将模块层次分割出来，这就有了中间层（局部）模块的按需加载需求了

5. 正因为按需加载，所以有必要使用规范的模块格式

6. 模块及依赖的识别，以及生成模块树

   
   

综上所述，我们形象地说希望构建Webpack+RequireJS的一个工具