提个SPM3在Seajs2.3.0使用下的傻瓜问题

[gumutianqi]

升级到了SPM3，之后，package管理也更加方便了。不过在seajs中的使用发现了一个小小的问题。就是对于seajs中seajs.config({// 配置}) 问题。

 alias: {
        'jquery': 'jquery/2.1.0/jquery',
        'zepto': 'zepto/1.1.3/dist/zepto/1.1.3/index',
        'transit': 'transit/0.9.9/dist/transit/0.9.9/jquery.transit',
.....

spm3 install 下面的模块是源码，build后，生成dist目录，那seajs的alias配置，如果不指向dist目录就得不到有define包裹的模块，如果配置成指向dist目录的路径，发现require的时候模块console出来是null的，而如果我把dist目录下面的copy出来，变成'zepto/1.1.3/index'',源码那些删掉，require又是正确的的。

我不知道这里是seajs2.x配置问题，还是spm build问题。我该怎么处理。
如果每次build了，还需要copy出来，那岂不是很麻烦，而且，实际website项目中，还需要spm build逻辑代码，这时候有需要alias配置的目录下面必须有package.json文件。

@lifesinger @sorrycc

[sorrycc]

前面遇到要 copy 出来才能用的问题是因为 build 出来的 id 和 require 的 id 不一致，不能这样用，换一种方法吧。

目前有两种方法：

1. 客户端，seajs-wrap
2. 服务端，spm doc watch 或基于 serve-spm 封装

[army8735]

昨天也发现了，alias对于开发无id和build有id逻辑不一致，是个大坑

[sorrycc]

开发模式下，如果 base 是项目根目录，alias 就要包含 sea-modules，格式是 sea-modules/{{name}}/{{version}}/{{main}}

[gumutianqi]

@sorrycc

目前有两种方法：

1. 客户端，seajs-wrap
2. 服务端，spm doc watch 或基于 serve-spm 封装

还是不大理解，这个坑要怎么填啊。
seajs-wrap是建议在开发模式下使用，那么当部署到线上呢？
能否给个具体的demo，之前的seajs.org的demo已经不适用与现在的spm3和seajs2.2.x+了。
关键还是seajs配置的问题。

我的base: '../sea-modules/',

目录结构是seajs之前项目推荐的结构

app //html页面
sea-modules
static > 静态资源和逻辑js
static > config.js //seajs 配置文件
static > page/*.js //实际项目中的page逻辑js

[afc163]

build 到 dist 中的文件并不是直接放在 dist 目录进行使用的。

一般来说，package 的开发目录和线上 cdn 文件的目录当然是要分开的。你不应该把整个 package 的源码也部署到线上吧？

所以，典型的开发流程应该是，在 package 的开发目录进行 build，build 出来文件 dist/example/1.0.0/index.js，你需要把 dist 下的目录结构和文件（不包括 dist 啊）部署到 http://cdn.example.com/example/1.0.0/index.js 这样的对应位置上。（这个部署需要你自己不管用什么办法来完成）

然后再使用 seajs 进行调用。

<script src="http://cdn.example.com/path/to/sea.js"></script>
<script>
  seajs.config({
    base: 'http://cdn.example.com/'
  });
  seajs.use(['example/1.0.0/index'], function(now) {
    console.log(now);
  });
</script>

[afc163]

你的 alias 路径根本就不合理啊。

"transit": "transit/0.9.9/dist/transit/0.9.9/jquery.transit"

目测你把整个 package 连带 dist 这一层结构都作为线上部署的路径了。

[gumutianqi]

@afc163 目前还不是线上部署，seajs1.x的时候，线上部署肯定是连*-debug.js 文件都去掉了的

[afc163]

好吧，我也看错了。

楼主是到 sea-modules 里面去 build 了吧？希望自己的模块能直接使用 sea-modules 下的模块 build 之后的代码？

其实你并没有新建一个模块用标准的方式来引用 sea-modules 下安装的模块。

spm3 中，安装到本地的只会是源码，而非构建后的代码。建议楼主新建一个标准的 spm 模块，用 require 和 spm doc watch 来调用和调试你的逻辑。完成开发后，build 你的模块（它会把 sea-modules 下的模块一起构建进来，无须单独构建它们）就可以在线上使用了。

[gumutianqi]

@afc163 按照你的回复，那就是真的需要copy出来，我单独一个web项目来管理SPM模块，build以后copy到要使用的项目，这样子。
至少我不需要考虑seajs-wrap带来的新问题，而且seajs-wrap只适用于开发环境，刚刚又试了spm doc watch，配置了website的package.json ，build成功，访问后，发现连标签导入的sea.js 也给加了define，就出现了define is not defined，带来了新的问题

[afc163]

不知道你的 website 的目录结构是什么样的，还是建议按照 spm init 生成的目录结构来开发模块，无论是通用前端模块，还是业务模块。

至于在 website 项目中再调用模块，这就不是 spm 的职责了。

[gumutianqi]

@afc163 @sorrycc
开发模块没有问题，完全是spm init的结构。
我大概明白了，应该可以说新版本的SPM和seajs整合不是非常好，需要一个中间环节，如果spm能够提供一个命令把sea-modules下面的模块都打包到一个新的目录，我再把这个目录用来配置seajs使用，或者上传到cdn上直接部署，就完美了。

本地调试seajs开启debug模块，使用*-debug.js那个文件，上线和本地开发环境也能保持在一个环境中，跟seajs1.x的时候比较像。

seajs1.x上线时候，我也只是将sea-modules文件下的所有文件上传到cdn，更改一个seajs的base配置这么简单。

[afc163]

现在我们更推荐使用 include=standalone的打包方式来进行开发，即加载器、当前模块和依赖模块都打包成一个独立的包，用 script 引入即可使用，无须额外引入 Sea.js 。如果业务环境允许的话，可以尝试使用这种方式来开发。

但如果使用默认的 include=relative 的方式，对于楼主来说，的确没有直接的办法来获得并所有的依赖模块并部署（现在只能挨个 clone 到本地进行 build 后再部署到 cdn），这个需求我们后续会仔细考虑一下，因为我们也有类似的难题。

具体问题总结是：第三方在使用 include=relative 的打包部署方式时，如何快速部署依赖模块？或者是如何快速获取需要部署的依赖模块的 dist 文件？

感谢反馈和讨论~

[sorrycc]

那么多包，手动发布肯定要累死。。

基于之前接收到的信息，能想到个人觉得比较理想的是云端 build 的方案，具体如下：有个 build-server，输入 name@version，输出 build 后的 dist 目录里的 tar 包，然后发布脚本调这个接口获取文件执行发布。

[sorrycc]

@gumutianqi seajs 被加 define 的问题，可以加 ?nowrap 参数来解决。

<script src='path/to/sea.js?nowrap'></script>

[afc163]

云端构建发布我们是可以做，第三方怎么办？部署的位置和我们又不一样。

要有个方式让人方便的拿到需要部署的依赖模块的 dist 文件。

[gumutianqi]

@sorrycc 加?nowrap的方式我不是很能接受，部署的时候可能还要去挨个去掉，这样会给后续带来更多的问题，还不便于协同开发。@afc163 说的：

具体问题总结是：第三方在使用 include=relative 的打包部署方式时，如何快速部署依赖模块？或者是如何快速获取需要部署的依赖模块的 dist 文件？

我想问题就根本就在这里，让开发环境和部署环境之间的切换变得方便，能够快速的拿到需要部署的依赖模块的 dist 文件是最好的，不一定非要搞什么云端部署。

非常感谢 afc163 sorrycc 对该问题的反馈和回答。
不知道seajs的@lifesinger，射雕怎么看，不希望看到spm和seajs之间存在分裂。
从seajs的第一个版本用到现在，感情深厚啊

[afc163]

还是建议用 include=all 或 include=standalone 啊。

按我的想法，spm 会逐渐淡化 seajs 的存在，spm 本身就是比 seajs 更大的概念。

[lifesinger]

seajs 只是一个 loader，spm 仓库是各种模块组成的海，spm 不需要考虑 seajs 呀，特别要小心不能有强耦合。spm 不是淡化 seajs 的存在，而更应该进一步无视 seajs 的存在。这不是分裂，是更好的发展方向。

[afc163]

之前都认为 spm 是 seajs 的一个打包工具。现在应该是 seajs 是 spm 的一个在线下线上的加载工具。

[niphor]

本来是想用spm和seajs来加速开发，结果是越用越蛋疼。

• 同LZ的问题，sea-module里面还得自己再build...
• spm@3x的package又少得可怜，遇到个没有的，还得手动下了放指定位置，再改package.json
• 和bower什么的不兼容，sea-module文件夹只能放在根目录，想想 向开源项目推广 spm 的汇总（spm popularize） #781 里面打钩的才占1/3....，混搭使用要多蛋疼有多蛋疼。

兼容性还是个问题：

• 代码打包强制加wrap，也不检查里面是不是有define什么的了，以前一堆代码得修改，增加不少工作量。
• spm@3x可能还在开发中，有不少Bug，那我换回原始点的打包方式，结果grunt-cmd-transport和grunt-cmd-concat都早就不在更新了，里面handlebars支持都还只停留在1.0.0rc,，也不知道是不是有什么其它的Bug存在，下下来还得手动改。又增加了复杂度...
• spm doc watch居然是用markdown，不写前端还好些，万一是个前端js，各种html又是各种麻烦。

想想spm build出来的东西还不是都加了wrap，都是为了前台，还不是得用加载器来加载

搞到现在，最终还是直接自己写两个简单的grunt task来的简单舒适。

我也只能自己笑自己战不动了。

也许这东西谁开发的更适合谁吧...

[gumutianqi]

@afc163 @sorrycc 希望有build的解决方案了，能够第一时间告知;
email: gumutianqi@gmail.com

[afc163]

@gumutianqi 试试这个：https://github.com/hotoo/spm-build-deps

[sorrycc]

同 #883，fixed in 8432eb8