spmjs/spm

spm@3.0 和 spmjs.org 的未来

afc163 opened this issue · 13 comments

afc163 commented

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

思考

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

原则

  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 commented

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

edokeh commented

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

lepture commented

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

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

single entrance

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

这可都是我想要修改的呢

afc163 commented

so 快回来做吧！

hbrls commented

会考虑做类似 yeoman 的事情吗

yukai44444 commented

可预见地会变得更美好

bobodeng commented

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

popomore commented

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

popomore commented

哪里看出用 AMD 了

fengmk2 commented

@afc163 说到

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

yiminghe commented

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