Description
RT
业务模块怎么办？也得像写一个组件一样，依次spm init,spm build,spm publish吗？
如果不使用spm打包，仅仅使用seajs和seajs-wrapper插件，业务模块都是commonJS规范的模块，没问题，页面功能都可以跑，但是不打包上线，已经不符合现代网站的趋势了。
说一下我当初使用spm2.x的构建流程：
去年spm3还没发布,摸索了很久，为了使构建后的模块ID和加载路径一致（否则factory不执行）,几经折腾发现了idleading这个打包参数，最终完成打包任务。
web组件的确是像官方推荐的那样依次spm init,spm build,spm publish，并搭建了私有spm源服务器用以管理这些模块。
但是业务模块并没有发布到spm服务器上，只是和项目代码放在一起，比如a.com/assets/scripts/app/user/new.js 这样的路径（也没有使用spm init，外表看来只是一个普通的js文件）。
开发时，业务模块都是CMD模块，运行没有问题。
当开发完毕后，打包，在scripts/目录下运行一条命令（比如sh build.sh，一个命令别名）.
它的流程是，首先，利用nodejs的fs模块，遍历出该目录下所有需要打包的js文件，最后生成package.json，将上述的js列表写入spm.output数组(比如其中一个是app/user/new.js)。
然后调用 spm build -O _spmout,此时package.json中的idleading已指定为/assets/scripts/_spmout/，最后打包出来的模块ID类似于/assets/scripts/_spmout/app/user/new。
当然，页面上seajs.use的路径也要相应添加一层_spmout/.
也就是说，运行一条命令就可以把所有CMD业务模块打包输出到另一个目录下，页面seajs.use的路径切换到该目录即可。或者可以勉强理解为，我把所有业务模块作为一个“组件”里的模块，build时一起打包了。
spm2.x的idleading默认是{familyname}/{version}，随着组件的不断升级，版本号也随着升级，即增量发布。
而我这个idleading方案，没有做增量发布(要做也可以，只要每次build的时候，给idleading添加版本号后缀即可，页面引用也相应更改）。我不知道我这样的做法是不是属于hack，但它的确可行。
但是如果业务模块也像web组件那样编写，我想我会crazy掉。
看到spm3发布了，我也是很兴奋，打算“炮制”一份spm3的打包版本，依然找到了buildArgs中的idleading,设置它，发现构建后的模块依赖数组中的依赖模块idleading全都是这个设置值了。。。
这就没法玩了啊~~~
先不讨论spm3的idleading这个行为是不是bug，我只想请问，如何“正确”使用spm对业务模块打包？