spm@3.0 和 spmjs.org 的未来

[afc163]

经过下午的讨论，团队内基本达成了一致。

思考

一定需要改吗？
是否改了就会更好？
如何衡量好坏？
如何避免换一波人就改一遍？

原则

1. 更加开放的 spmjs 生态圈
2. 保持优点、取长补短

现状

1. 命令行工具 - spm、插件和 apm
2. 包管理平台 - yuan 和 spmjs.org
3. 构建方案 - grunt 和 spm build
4. 书写规范 - CMD 规范
5. 源码 - github 和 gitlab
6. 内部使用 - yuan.alipay.im
7. 文档工具 - spm doc 和 assets.spmjs.org

问题

1. 较为封闭的方案，开源类库要想向 spmjs 提交模块非常麻烦。需要修改目录结构并自行构建
2. 构建方案极其复杂，门槛奇高
3. 非本地调试，依赖 assets.spmjs.org
4. CMD 书写规范并不通用，难以推广，所以才有了 https://github.com/cmdjs/gallery 这恶心的玩意
5. package.json 不规范
   • family 应该放到 spm 字段里
   • 依赖（alias）十分啰嗦
   • src 和 dist 无法在 package 里自定义

比较

业界方案们

1. component
   • component.json
   • CommonJS
   • 使用 github 作为仓库，没有包管理。
   • 构建后使用。
   • 暂无版本号方案。
2. bower
   • bower.json
   • CommonJS 和 AMD
   • 使用 github 作为仓库，没有包管理。但有一个单独的模块注册和索引服务。
   • 没有发现打包方案
3. jamjs
   • package.json spm.jam
   • AMD & requirejs
   • 自建的包管理系统 jamjs.org
4. browserify
   • package.json
   • CommonJS
   • npmjs.org

业界方案的优点：

• 简单，门槛低，尽可能利用现有打包和包管理的方案
• 支持 CommonJS 和 AMD 的写法，使很多类库接入非常方便
• 目录结构灵活
• 单 ID 和单入口，使模块更容易上手
• English

业界方案的缺点：

• 基本上都是打包成一个文件的方案，适合独立页面应用，不适合多人协作的页面
• 依赖非常鸡肋，一旦出现依赖需要打包才能使用，导致大多数模块都没有依赖。（可以想象你依赖了 jQuery 后打包有多悲剧）
• 没有静态文档生成工具，这对 browser modules 来说是一个悲剧。
• 慢
• no seajs

探讨点

实际上这些探讨点决定了下面的目标，以及是 spm@3.0 还是 spm@2.5。

1. CMD or CommonJS

   采用 CommonJS 方案，和业界保持一致。

2. 去除 family

   达成共识，去

3. 发布到源上的是打包后的还是源码

   源码。发布不依赖构建，构建只是为了线上的最终使用。

4. ID 规则和规范

   arale/dialog/1.0.0/dialog -> arale/dialog/1.0.0/dialog.js
   

   arale.dialog -> arale.dialog/1.0.0/index.js
   

5. single entrance

   南伯一直想做的一点，没有做成主要是因为在业务模块中需要输出多个文件。

   "spm": {
    "output": ["a.js", "b.js"]
   }
   

   "spm": {
    "main": "index.js",
    "style": "index.css"
   }
   

6. 包管理方案

   目前有四个选择 npm、cnpmjs、github & gitlab、spmjs。

   • npm
   • 优点：不用自己维护
   • 缺点：慢，browser 端模块难以沉淀出来
   • cnpmjs
   • 优点：快，不用自己维护
   • 缺点：不适合 browser 端模块，private 和同步机制对我们来说没用
   • gitxxb
   • 优点：不需要实现额外的包管理平台，操作简单容易上手
   • 缺点：慢，gitlab 和 github 上需要维护同一个模块
   • spmjs（选这个）
   • 优点：最满足 spmjs 生态圈的要求，适合前端模块
   • 缺点：需要自己维护，python写的，不太好改

方案使用 yuan 来搭建，需要改成 node 版本。（虽然很痛，但为了后期维护必须做。。）

目标

1. 新的 spm package 规范，方便推广到前端社区（希望能把 spm 字段加到各个著名的项目里去）
2. 保存源码的包管理平台，也就是新的 http://spmjs.io
3. 灵活和简单的打包构建方案，构建和包管理彻底解藕，发布前不再需要 build。spm-build & gulp?
4. 本地化调试方案（已经参照 component 和 jam 方案进行了实验，基本可行）
5. 文档英文化
6. 公司内部的升级方案

方案

1. update spm package specification
2. spm 3.0 整合现有插件为一个库，支付宝插件放到 apm 中
3. spm build 新版本，整合 cmd-util
4. 本地调试方案和 spm doc 新版
5. 重写 yuan 为 nodejs 版本，技改加升级
6. spm1.x 和 spm2.x 项目升级到 spm 3.x 的转换工具

计划

应该是一个半年以上的长期规划，待我梳理下。

1. 2014年1月
   • 完成 spm package specification
   • 本地调试方案（spm-doc 和 nico-cmd 的改造）
2. 2014年3月
   • 完成 spm@3.0 的开发
   • 完成 spm-build 的整合改造
   • 必要的插件功能进行整合
   • apm 配合开发
3. 2014年5月
   • 完成 node 版本的 yuan 改造和升级
   • 新的 spmjs.org 的部署
4. 2014年6月
   • 开发模块迁移工具
   • 进行 Arale 模块和 Alice 模块的改造迁移
5. 2014年7月
   • 中英文文档建设
   • 新的 spmjs.org 的部署
6. 2014年8月
   • 正式发布 spm@3.0 整体方案
7. 2014年8月及以后
   • 尝试在支付宝站内进行迁移和改造

[afc163]

spmjs/spm2#110 全部转到这里讨论。

[edokeh]

yuan 的 HTTP 接口修改了以后能提供个文档嘛？
写 spm-yuan 的时候又是翻源码又是抓包的好累啊

[lepture]

方案使用 yuan 来搭建，需要改成 node 版本。（虽然很痛，但为了后期维护必须做。。）

采用 CommonJS 方案，和业界保持一致。

single entrance

源码。发布不依赖构建，构建只是为了线上的最终使用。

这可都是我想要修改的呢

[afc163]

so 快回来做吧！

[hbrls]

会考虑做类似 yeoman 的事情吗

[yukai44444]

可预见地会变得更美好

[bobodeng]

关注一下……
另外，南波汪找到妹子了吗？

[popomore]

@afc163 是不是建个 3.0 的 milestore，把你做的记录一下。

[fengmk2]

挖坟帖 http://duojs.org/

[popomore]

哪里看出用 AMD 了

[fengmk2]

@afc163 说到

http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging
这文章里的内容真是和 #718
我们之前总结的差不多

[fengmk2]

http://weibo.com/1026058784/BuK2S3hza

[yiminghe]

browserify/gulp 插件机制很好，spm 构建需要支持下,源还是建议 npm/cnpm，方便全端共享代码