spm.js 模块生命周期解析

JS 模块的解析流程

目前解析是通过定义模块的生命周期来完成的，下面主要分析JS模块默认处理流程

资源输出（resources）

• 资源输出（resources）：在处理源码前，会把文件输出到 _build 一个临时目录中，然后后续对文件的操作都会在这个目录进行。我们在输出中也可以进行一些简单的变量替换。
• 预合并（combine）：允许对一个复杂的模块，进行物理拆分，也就是说拆分后的代码只有合并到一起了才是一个完整的模块。

编译（complie）

• 目前支持 coffee、less 等文件格式的处理
• 允许对第三方模块的 transport
• json 检查对 js 模块的处理

模块分析（analyse）

在这个阶段主要进行代码的语法检查（init），依赖分析（dependencies），依赖冲突检查（depCheck）等操作

依赖分析（dependencies）

• spm 会分析 _build 目录中的 js ，然后会计算出来这个模块的依赖模块列表，包括全局和相对模块
• 对于外部模块，还回去分析模块的依赖
• 有些模块是合并模块，spm 也会对依赖重复进行排除
• 对于外部模块的依赖列表进行全局化处理，也就是把原来的相对关系改成绝对关系

依赖冲突检测（depCheck）

主要检查统一模块中间不同版本的冲突检查

预打包（preBuild）

• 模板的处理，允许对 tpl、html 这类模板文件内嵌到 js 模块中
• css的处理， 允许样式内嵌到 js 模块中

合并处理（output）

主要就是按照output的配置，对模块合并输出

打包（build）

对模块进行统一的收尾工作
– min 模块压缩
– install 安装到本地缓存
– zip 是否打成 zip 包

上传到源中（upload）

• pack 默认打包成 tar 包，然后进行上传
• upload 会把 tar 包上传到我们配置的源中

部署到指定地方（deploy）

具体参考 spm deploy

上面看到的 resources、compile、analyse、preBuild、output、build 就是定义生命周期的各个阶段，而每个阶段中我们通过组合一系列插件来完成我们对应的工作。这样的一个好处就是通过这样的划分，我们可以很容易的把对应的任务产分到对应的地方。这样整个处理流程就完成了