问题感觉主要还是前端的模块化和代码管理缺乏统一的标准. 每个公司可能都有自己一套方案. 这样就导致了很难有一个工具能够适用所有情况. 我个人觉得这和 java 社区的 Maven 发展有点类似. 早期也是 Ant 独占天下, 大家都是按照自己的方式通过写 Ant 脚本来管理. 但是这种方式相对也是比较落后的. 但是随着Maven的出现和大家的认可, 越来越多的开源项目都开始通过 Maven 管理. 然后为了更好的利用这些资源. 各个公司也越来越多的开始使用 Maven了, 而且也更加认可 Maven.

但是我们面临的阻力其实更大. 因为目前我们的方案在国外好多开源项目中并没有使用, 所以才有了我们的 transport, 这个也基本上保证了使用了我们套东西, 大部分好的开源项目也是可以用的.

我感觉可以从下面2个方面继续:

• 继续完善我们的生态圈, 包括更多开源项目的引入, 还有就是能有更多的人和公司参与进来呀.
• 工具本身更加完善. 就像 @popomore 上面提到的.

spm 应该走向全面的前端静态资源管理，就像 FIS

简单地说， transport 大家的标准完全无法统一。。

期待大家的讨论。

支持 fis 方案

支持FIS，对于解释性的后台语言没有问题，但是编译性的后台语言的话。。。貌似没那么好搞啊？

@newtonniu 如果用模板的话和后台语言无关。就算用类似 jsp 的的语言也可以先用 fis 处理再做编译。

@popomore .NET呢，貌似不是很好处理？模板用FIS模式的确没有问题，但是会打乱发布流程！

设计的时候就放到发布流程中就不算打乱了吧，这个要针对具体的流程看如何处理。

.net 不太熟悉，支付宝是 java 的，我们用 fis 的难点主要是历史架构的兼容上面。

@popomore 兼容的确很头疼，坐等下面的讨论~

到现在搞不好 one page app 打包的表示非常关心文档...

文章没提 SeaJS 和国外社区关系怎样?
Github 相关英文社区大量博客和项目都有 RequireJS 相关内容, 以及 echojs 和 stackoverflow 上文档,
看翻译说的, RequireJS 和整个 JS 社区关系都够紧密 http://cyj.me/why-seajs/requirejs/#why-amd
SeaJS 是想和 RequireJS 比吗, 这方面有做什么吗?

我简单的说说我个人的拙见吧。
从spm的项目立意来说呢，是很好的，期望有一种方式去解决各个js之间的互相依赖，互相引用的一些问题。建立一个库的机制去做这些事情。想到类似的可能也就是用途大概类似与java的maven。

但是java跟js最大的不同是，java是一门强语言类型，有比较完善的包管理机制。
js其实也是后来提出来了一个commonjs这个东东。希望建立一个健全的属于js的包管理机制。不管是cmd，或者amd都是好的，能抓老鼠的猫就是好猫。
ok，第一个问题解决了。seajs提供了一套干净的api，方便大家可以编写模块化的代码。
其实这里有些地方是有坑的。比如如果找了一个比较干脆的原生的js库，或者说是把现有代码转换成模块化的一些东西，确实是需要时间跟精力的，还容易出错！对于前端来说，出错是常有的，但是出错了，默认配置下，连常有的错误信息都没办法输出！抛出异常错误得有多难！你这个不是坑吗？比如你这个transport转后，出了点问题就只能爬文。但是爬的文还有可能是老版本的。然后惊恐的发现，这个已经不支持了。
所以说，对于seajs的官网的文档的建设能够明确好相对应版本的文档，让人可以一目了然。而不是从github的讨论帖中寻找想要的信息。
关于最后上线发布的压缩。我就不说了，什么id，什么spm，什么grunt。你能不能给个准信。哪个有用？怎么用。你们怎么处理的。
希望国人的出品的软件，能够真正的做到kiss，而不是口号是kiss。spm库里面还有一些库根本没法正常使用，需要自己去解决。或者对于入库软件的质量，你们根本不在意吗？只要求量？
其实有些后悔用seajs了，到处是坑，有解决问题的时间，自己写一个适合公司项目的模块加载软件不是更好？

不如，确定死了，合并压缩只用grunt、spm只用来模块管理。

在 2013年10月12日下午6:25，xccvista notifications@github.com写道：

我简单的说说我个人的拙见吧。

从spm的项目立意来说呢，是很好的，期望有一种方式去解决各个js之间的互相依赖，互相引用的一些问题。建立一个库的机制去做这些事情。想到类似的可能也就是用途大概类似与java的maven。

但是java跟js最大的不同是，java是一门强语言类型，有比较完善的包管理机制。
js其实也是后来提出来了一个commonjs这个东东。希望建立一个健全的属于js的包管理机制。不管是cmd，或者amd都是好的，能抓老鼠的猫就是好猫。
ok，第一个问题解决了。seajs提供了一套干净的api，方便大家可以编写模块化的代码。

其实这里有些地方是有坑的。比如如果找了一个比较干脆的原生的js库，或者说是把现有代码转换成模块化的一些东西，确实是需要时间跟精力的，还容易出错！对于前端来说，出错是常有的，但是出错了，默认配置下，连常有的错误信息都没办法输出！抛出异常错误得有多难！你这个不是坑吗？比如你这个transport转后，出了点问题就只能爬文。但是爬的文还有可能是老版本的。然后惊恐的发现，这个已经不支持了。
所以说，对于seajs的官网的文档的建设能够明确好相对应版本的文档，让人可以一目了然。而不是从github的讨论帖中寻找想要的信息。
关于最后上线发布的压缩。我就不说了，什么id，什么spm，什么grunt。你能不能给个准信。哪个有用？怎么用。你们怎么处理的。

希望国人的出品的软件，能够真正的做到kiss，而不是口号是kiss。spm库里面还有一些库根本没法正常使用，需要自己去解决。或者对于入库软件的质量，你们根本不在意吗？只要求量？
其实有些后悔用seajs了，到处是坑，有解决问题的时间，自己写一个适合公司项目的模块加载软件不是更好？

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/959#issuecomment-26194997
.

现在就是这样的哦

spm 是纯粹的包管理
合并压缩等等都是用 grunt 去做

2013/10/12 wxnet2013 notifications@github.com

不如，确定死了，合并压缩只用grunt、spm只用来模块管理。

在 2013年10月12日下午6:25，xccvista notifications@github.com写道：

我简单的说说我个人的拙见吧。

从spm的项目立意来说呢，是很好的，期望有一种方式去解决各个js之间的互相依赖，互相引用的一些问题。建立一个库的机制去做这些事情。想到类似的可能也就是用途大概类似与java的maven。

但是java跟js最大的不同是，java是一门强语言类型，有比较完善的包管理机制。

js其实也是后来提出来了一个commonjs这个东东。希望建立一个健全的属于js的包管理机制。不管是cmd，或者amd都是好的，能抓老鼠的猫就是好猫。
ok，第一个问题解决了。seajs提供了一套干净的api，方便大家可以编写模块化的代码。

其实这里有些地方是有坑的。比如如果找了一个比较干脆的原生的js库，或者说是把现有代码转换成模块化的一些东西，确实是需要时间跟精力的，还容易出错！对于前端来说，出错是常有的，但是出错了，默认配置下，连常有的错误信息都没办法输出！抛出异常错误得有多难！你这个不是坑吗？比如你这个transport转后，出了点问题就只能爬文。但是爬的文还有可能是老版本的。然后惊恐的发现，这个已经不支持了。

所以说，对于seajs的官网的文档的建设能够明确好相对应版本的文档，让人可以一目了然。而不是从github的讨论帖中寻找想要的信息。
关于最后上线发布的压缩。我就不说了，什么id，什么spm，什么grunt。你能不能给个准信。哪个有用？怎么用。你们怎么处理的。

希望国人的出品的软件，能够真正的做到kiss，而不是口号是kiss。spm库里面还有一些库根本没法正常使用，需要自己去解决。或者对于入库软件的质量，你们根本不在意吗？只要求量？

其实有些后悔用seajs了，到处是坑，有解决问题的时间，自己写一个适合公司项目的模块加载软件不是更好？

—
Reply to this email directly or view it on GitHub<
https://github.com/seajs/seajs/issues/959#issuecomment-26194997>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/959#issuecomment-26195095
.

王保平 / 玉伯（射雕）
送人玫瑰手有余香

我觉得抱怨是没有用的，这样吧，我会我修改的提交代码。希望为中国的开源事业做出一些贡献。

好，非常期待

2013/10/12 xccvista notifications@github.com

我觉得抱怨是没有用的，这样吧，我会我修改的提交代码。希望为中国的开源事业做出一些贡献。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/959#issuecomment-26197508
.

王保平 / 玉伯（射雕）
送人玫瑰手有余香

我觉得可以从源和构建两方面去优化。

源

原来的源范围太小，适用面不广（JS 模块 > CMD 模块 > Transport 的 CMD 模块）。原来源中存放的是 Transport 后的 CMD 模块，而且这个 Transport 规则是支付宝使用的，并不一定符合其他人使用习惯。

我觉得源应该更加开放，里面存放的代码不应该是构建后的，而是应该源码，应该是构建前的 CMD 模块。更激进的想法是源中存放的就是 CommonJS 模块，这就和 component、bower、browserify 相似了。

而包管理工具就可以用 component、bower、browserify 等，甚至于直接用 npm。

构建

如果按照上面的优化，构建就不需要和源及包管理扯上关系了，是代码能使用的最后一步。构建也分成两种，本身的构建和依赖的构建。

• 本身的构建：代码是由本人开发的，在发布之前需要构建。
• 依赖的构建：代码是别人开发的，而我开发时需要使用，所以也需要构建。

构建的步骤应该先用包管理工具下载依赖，下载下来的还是源码，之后就将代码编译打包。这一步构建的规则就可以自定义了，所以分享和构建并不冲突。

PS: 听说 fis 也在搭类似源的东西，可以共建

seajs很不错，很简单很好用，可是不客气地说，构建的配套做得不好

官方引导把构建从spm转向grunt，可是配套的grunt插件与spm的行为表现完全不一致：
spmjs/grunt-cmd-transport#54
spmjs/grunt-cmd-transport#55
spmjs/grunt-cmd-transport#56

昨天还发现了一个，spm build的时候只要指定了output，就会自动分析该文件的依赖，找到所需的模块。grunt-cmd-transport需要自己指定，问题是项目规模比较大，这么多模块都去人工指定是不可能的。可以通过dynamic src-dest部分解决，问题是需要人工排除掉不提取的源文件。总之是需要人工干预，没有spm那么方便

而且这些坑，都是在构建过程中一个个踩到的，文档上都没有提到，太伤了。。。spmjs，seajs，grunt-cmd-transport，grunt-cmd-concat的所有文档和issue我都看过了好几遍。PS：感觉spmjs那边对issue的答复也比seajs慢不少

@kyfxbl spm-build 也是基于 grunt 写的，只是很多人不适应这套方案，才提供扩展性强的 grunt 插件，spm-build 基本就是支付宝内部在用。

做一个工具不可能照顾每个人的需求，好一点的工具能让别人来适应，但 spm 不够好。

@popomore

可是grunt-cmd-xxx插件有坑呀。。比如54,55,56，或许是我自己使用不当，但是针对这些场景，希望官方也能给出最佳实践或者建议。。。我现在也搞不清楚这些到底是插件的缺陷，还是我自己使用错误。能读的文档我已经读完了。。

Grunt 很灵活，但使用成本也很高；spm-build 简单但扩展性不强；我们以前是这样区分两个工具的，所以你用 grunt 就势必要知道构建的流程，这里面就涉及到方方面面。

PS: 文档不好写，求文档高手。

@popomore

文档我可以写了贴上来，实际上54的场景，我们就完全调整了目录结构来适应grunt-cmd-transport；55的场景，我也自己写了一个grunt custom task，过程也发出来了。但是56，感觉是grunt-cmd-transport的一个BUG，这就不是文档能解决的了

57我现在也准备写一个custom task来解决

读完文档还不能解决的，建议继续阅读源码。。。

56是BUG吗？

原来 spm@1.x 的方案就是我们自己来构建，妄图解决业界所有的构建需求。

现在用 Grunt 来打包，很重要的一点诉求就是我们不再提供构建流程，只提供构建的 Task 和构建的目标。这个需要业界利用 Grunt 的生态环境自己去探索。

加油，把新方案系统完善起来，想好了，就去做。

和 Chair 一样，新的源、包管理方案，也整理出一份系统的文档出来，做为一个重要方向去做。

这一块让偏右牵头来做，可行？

2013/10/30 偏右 notifications@github.com

原来 spm@1.x 的方案就是我们自己来构建，妄图解决业界所有的构建需求。

现在用 Grunt 来打包，很重要的一点诉求就是我们不再提供构建流程，只提供构建的 Task 和构建的目标。这个需要业界利用 Grunt
的生态环境自己去探索。

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/959#issuecomment-27367557
.

王保平 / 玉伯（射雕）
送人玫瑰手有余香

不做，天天折腾这个干嘛，现在费了老大劲好不容易稳定下来了，有点时间搞些更有价值的不是更好。spm@2.x 本来都不应该出现。

技术人员一闲下来就天天瞎折腾。

个人比较期待的是一套方便的开发方案, 前端大小的应用做起来坑很多
在坑被填平能快速前进之前对酷的技术只表示观望的状态..
现在用 SeaJS 的话, 国外新的模块都不会提供原生的方案, 不小心还得自己打包,
这个过程比较烦, 个人的小项目想想用 RequireJS 直接引各种类库官方提供的代码得了.

比较期待的是文档, 社区文章推荐方案, 以及各方面丰富的模块
我完全觉得浏览器还是 ES 标准都掌握在外国人手里, 纯 JS 玩不出啥惊心动魄的
当然个人小项目和支付宝的模块方案搭上挺少, 纯个人观点

spm还真心不好用，目前公司的项目都用上了seajs，构建都是基于grunt，还算方便。但seajs还没得到“国际认可”，模块需要手动打包确实增加不少使用成本，与其说是spm的困境，还不如说是seajs的困境。
另外seajs也仅仅解决了模块化开发、加载一个问题，前端的静态资源文件管理，自动化发布、部署等问题还是需要用到类似fis这样的解决方案，当然个人对fis也不是很感冒，还是想自己基于grunt造一个轮子，也许适合自己的才是最好的

+1 适合自己才是最好的

@newtonniu 能具体介绍一下如果 .NET 项目使用 fis 所产生的影响吗？比如影响发布流程，怎么影响了等。因为这次项目第一次用.NET，对.NET的运行机制等都还不是很了解

spm@3.0 和 spmjs.org 的未来，欢迎来这里讨论。

spmjs/spm#718

百度的同学基于fis写了一个这个https://github.com/fouber/spmx，感觉还是挺不错的

@elover
这个不能合并依赖文件吧？

我觉得这个你们应该可以帮他，如果两者能取长补短，seajs社区应该会发展的更好。

大半夜胡思乱想，思路比较乱，请拍砖。

不是一般混乱，不知所言。

加油。没事就来看看进度。。。

个人感觉整套生态链是：

• seajs
• 部署（合并，压缩）
• 包管理

seajs入门还是比较容易的，但是一到部署就很麻烦了（spm非常难上手!），部署麻烦其实给seajs生态发展造成很多麻烦

建议把seajs的demo的部署工具换成用grunt写的，比较通用简单的部署工具！

只有前两者（seajs，部署工具）充分发展了，包管理（spm）才会快速发展

最近研究了几天的seajs，总结如下：

优点：

• 用起来比较简单。
• spm下有不少不错的组件，比如arale/alice系列，拿来就用。我就是看重这个才用的。

缺点：

• alias的配置，需要单独引用一个js,或者是直接在页面中写一大坨。写在页面中不合适，再引用一个js,就需要2个请求了，一个seajs,一个config.js
• 构建跟发布太复杂，一会spm,一会grunt,翻了几天官网，没找到一个比较权威的，整个网站，打包发布的demo之类。希望提供一个比较好的发布demo。如果自己配置grunt 要费很多时间。
• 希望能像yeoman,fis那样，发布比较方便。一个命令直接搞定,版本号，依赖什么的，全部解决了

spm 的资料好少，按seajs的步骤，合并，都是一堆的错，让我很不解。

所以现在用require了，不知道，seajs，能不能搞个支持grunt的，配置不是那种有错找不出来的那种。

文档 http://docs.spmjs.org/

构建的其他例子 https://github.com/spmjs/spm-build/tree/master/examples