请问spm只适合构建web组件模块吗？

[stoneChen]

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对业务模块打包？

[sorrycc]

可以看下文档和例子：
https://github.com/spmjs/docs
https://github.com/spmjs/examples/tree/spm-webpack

[stoneChen]

@sorrycc 3Q，看过这两个文档了，ninjia那个版本不太明白什么意思，react那个demo似乎跑不起来，countdown的例子跑了一遍,没有问题，使用感觉良好。终于有一套针对业务模块的方案了，或者说项目级别打包方案，之前的spm都是针对组件的，导致我在使用spm2的时候各种hack。。。

3.6这个版本跨度有点大，需要慢慢消化。另外，我去恶补一下webpack。

[stoneChen]

@sorrycc 想起几个问题/感慨：
1.spm现在开发组件，是不是就不用打包了？开发测试通过后，直接发布就行吧，我记得源上存放的包就是源码，不是build过的。而spm2源上build过的。
2.spm开发项目，打包为standalone方式，似乎与seajs彻底分离了，把seajs模块的打包任务转交给了spm-sea，这才是spm->static package manager真正的意义么？在此之前，一说起spm总是会联想起seajs。
3.感觉spm的发展路线，逐渐疏远CMD规范了，就像玉伯说的忘记AMD,CMD，拥抱CommonJS。