平台：Windows 7
版本：1.7.7
简介
Sea.js实现了对JS代码的模块化组织，大大提高了前端开发效率。然而在实际项目中，大量的细分模块却导致大量的脚本请求，拖慢了页面加载速度，也给服务器造成不小的压力。针对这一情况，spm（static package manager）因运而生，专门用于打包、压缩Sea.js模块以及CSS文件。
Sea.js遵循CMD（Common Module Definition）模块定义规范，一个文件一个模块，清清爽爽。CMD模块定义形如：
define(function(require, exports, module) {
//使用require表达对其他CMD模块的依赖
//使用exports或module.exports或return向外抛出接口
});
spm的打包原理很简单，就是将这一形式（Modules/Wrappings）的CMD模块转换为Modules/Transport形式：
define("id", ["dep-1", "dep-2"], function(require, exports, module) {
//源码
});
这一过程仅仅是给模块换了个框框，spm需要完成的工作当然不止于此，主要可以概括如下：
1、如上述那样按照Modules/Transport格式在模块定义中加入标识和依赖，并把多个模块合并到一个文件中（包括CSS）；
2、将源码中的变量名、函数名等标识符简化为a、b、c这样的单字母，并删除空格、缩进、换行等空白符（所以最终你看到的是一长串拥挤的、可读性极低的代码）；
3、识别无用代码后将其删除，还有其他一些优化措施。
这些步骤在本地完成，都是静态的文本处理，过程并不复杂，如果用起来不满意，完全可以自己实现一个，甚至可以用C语言写。
安装
首先我们需要Node.js，到官网下载安装即可，完后记得把安装路径（如C:\Program Files\nodejs）加到环境变量Path里，在cmd中运行node -v查看版本以确定是否安装成功：
接着使用Node.js的包管理工具npm（node package manager）安装spm。spm版本已更新到3.9，但是从第3版开始转向了CommonJS规范，在打包前需要扒掉所有模块的define封装，项目中几十个乃至几百个文件都需要手动处理，实在犯不着。于是我们转投低版本——spm@2.x或spm@1.x，经过多次测试，spm@2.x的各个版本在安装或使用过程中总出现莫名其妙的报错，也许是与Windows兼容不佳（具体未能考证），只好拿spm@1.x将就将就——当然，spm@1.x已经可以满足所需。
安装spm前，如果Node.js装在了C盘，最好通过以下两行命令先修改一下npm的全局路径，否则spm的相关文件可能会无法正常写入磁盘：
npm config set prefix "D:\nodejs\node_global"
npm config set cache "D:\nodejs\node_cache"
（这里以D盘的一个路径为例，当然你得先新建好这两个文件夹。）
将spm@1.x安装到全局路径：
npm install spm@1.x -g
完成后，在刚才设置的node_global文件夹下可以看到spm的相关文件，其中spm.cmd就是主程序，将D:\nodejs\node_global添加到环境变量Path，执行spm查看版本和可用指令：
如未能顺利安装或安装后使用有问题可以执行如下命令卸载spm，而后尝试重装（其他版本）：
npm uninstall spm -g
使用示例
编写一个简单的示例，功能模块demo（位于modules目录下）包含a.js、b.js、c.js三个CMD模块，b和c放在subModules文件夹下，a作为入口调用b，b调用c：
通过seajs.use()在页面中调用a模块：
seajs.use(['modules/demo/a'], function(a) {
a();
});
下面我们使用spm将a、b、c进行打包。首先需要一个工作目录，比如D:\spmworkspace，将整个功能模块（本例中就是demo文件夹）放在这里，而后需要一个package.json文件，用于编辑spm build的配置信息：
"root"：功能模块的根目录名，这取决于它在整个项目中处于哪个位置。
"name"：功能模块的名称。默认情况下，打包后的Modules/Transport模块标识是对"root"、"name"和CMD模块文件名的拼接，如在本例中模块a的id就是modules/name/a。
"src"：源文件夹（要求与package.json在同级目录下），存放需要打包的JS文件们。
"to"：目标文件夹，用于存放打包后生成的文件。该文件夹会自动生成，也与package.json在同级目录下。
"output"：配置文件合并规则，这里配置的"a.js"要求在demo文件夹下必须存在相应的a.js文件。
配置好后，在cmd中来到工作目录D:\spmworkspace下，执行spm build：
此时在D:\spmworkspace下就出现了一个dist文件夹，里头包含a.js和a-debug.js两个文件，其中a.js是最终打包结果：
这是在项目上线时用的，在开发调试时，我们可以使用a-debug.js：
部署时直接将a.js替换原本的a.js即可，subModules下的b.js和c.js不再需要，完美运行：
可以看到，只加载了压缩后的a.js，文件总体大小和加载时间都大大缩减，在实际项目中打包的CMD模块越多，表现就越好，这就是spm的价值所在。
几点补充
require的路径问题
通常在项目开发中，require主要使用两种形式的路径载入其他CMD模块：
一种是相对路径，以./或../开头，这种形式用于同一功能模块之内JS文件之间的相互引用；
一种是全局base寻址形式，直接以文件或文件夹名打头，形如xxx/xxx，Sea.js会根据SeaConfig.js中配置的base路径来拼接出绝对路径，这种形式用于功能模块之间JS文件的相互引用，比如有个实现通用功能的util模块，其他功能模块中的JS通常会以require(util/utilA)的形式引用。
spm打包是针对单个功能模块的，无法找到以上述第二种路径形式require的文件，因此不会将它们打包进来。确实对于其他功能模块里的东西，也没必要都压缩进来。
如果一定要将它们一齐打包，就需要用到spm提供的C/S模式的源服务。使用spm server指令可以在本地构建一个源服务器，局域网内的开发者可以将打包好的各个功能模块部署上去，通过在C:\Users\Administrator\.spm\config.json中增加源服务器、在package.json中增加"dependencies"配置、"output"中的"."改为"*"，在打包时就可以加入在源服务中的其他功能模块。如此倒是提供了协同开发的可能性，但操作起来挺不方便，我也没有进行验证，如有不对之处，还望路过的大神不吝赐教。
多个入口文件的打包
在本文的demo示例中，整个功能模块只有a.js一个入口，它把其他CMD模块都牵扯到了，如果入口文件不止一个，或者说一些文件与另一些文件相互独立怎么办呢？比如在util下，有负责加法的add.js和负责减法的sub.js，它们之间互不引用，package.json可以这样配置：
"output": {
"add.js": ".",
"sub.js": "."
}
最终生成两个压缩后的JS，或者将它们强行合并：
"output": {
"util.js": ["add.js", "sub.js"]
}
图片的相对路径问题
比如在CSS中使用相对路径引用图片，在打包前表现正常，但打包后CSS内容并入JS中，被载入JSP或HTML页面，相对路径将以页面文件位置为基准，此时就需要调整图片文件的位置，在开发时使用绝对路径可避免这一情况。
CSS载入问题
实测表明，只有在入口JS中载入CSS才能正常打包，如果其他CMD模块require了CSS，spm将提示无法找到该CSS文件，这一现象很奇特，目前尚未弄明原因。
开发约束/建议（仅针对1.7.7版）
1、确保所有JS文件符合CMD规范；
2、入口JS文件（可以有多个）应放在功能模块根目录下；
3、避免使用相对路径require其他功能模块里的JS；
4、CSS的require放在入口JS文件中；
5、使用绝对路径引用图片。
学习资料
关于Sea.js
关于spm
2016年2月22日 无锡
