spm3 发布日志
afc163 opened this issue · 91 comments
spm3 发布通告
很高兴通知各位，更好用的 spm@3.x 及其源服务 spmjs.io 发布了。
缘起
spm 从第一个版本到现在三年了，从 0.x 到 1.x 再到 2.x，定位上从 Sea.js 配套的打包工具到包管理器，已发生了多次大的改变。
spm 的第一行代码提交是2011年7月9日。那时 npm 刚刚兴起，而 bower、component、browserify 等等还未出现。
相比于 Sea.js 的简洁通用，spm 的包管理和打包机制一直被社区所诟病（我相信有一万个issue吐槽过它），甚至或多或少阻碍了整个社区的发展，这也和我们做生态圈的想法相悖。（可以参考：spm 的困境）
这些年接触 nodejs 时，npm 社区的活跃和便利性给我们很大启发。我们(都)希望在自己的工作中能使用优秀的业界模块（而不是自己开发，或用公司的破框架重构一个），所以我们有了 Sea.js，有了 spm，有了 Arale，这些前端模块化的方案和工具都致力于解决一个问题：我们如何可以像 npm 一样方便的组织和调用模块，我们如何最小成本地来使用和贡献业界优秀的模块，我们如何能给开发者提供通用的前端模块化解决方案。
spm@2.x 在去年发布之后，对上面的问题做了很多解答。实际上，spm2 解决了大多数问题，它在支付宝和很多第三方企业和个人的项目中良好的运转，实践了很多工程问题（比如样式和模板的集成、内网源）。但是它也有很多问题，比如太多约定，比如暴露给开发者的复杂度，比如不通用……
所以我们需要一个更好的 spm@3.x。( •̀_•́)ง
定位
新的 spm@3.x 从其他包管理方案（browserify、bower、jamjs、component）中汲取了不少优点，在 spm2 的良好基础上，致力于提供一个开放、通用、完善、集成化的基于浏览器模块生命周期的包管理工具，包括初始化、编码、本地化调试、文档生成、发布、依赖管理、单元测试、构建、源服务等等功能。
进化
一起来看看 spm@3.x 都发生了哪些变化：
-
精心设计的 package 规范。
-
去除 family 字段。打通模块间依赖的壁垒，避免每个 family 下都发布要 jquery 的问题。
-
spm.alias 属性被语义更加明确的 spm.dependencies 属性代替。
-
添加了 spm.main 属性，实现了单入口，从而使依赖书写更加清爽。
原来你需要这么写：
"alias": { "moment": "gallery/moment/2.6.0/moment" }
现在清晰多了：
"dependencies": { "moment": "2.6.0" }
-
去掉了默认的 src 目录等约定规则，这样模块目录结构可以像 npm 模块一样简单随意。
-
新增 buildArgs 字段，用于模块构建。
-
-
编码书写规范从 CMD 规范全面转向 CommonJS，更加通用和开放，不再需要书写烦人的
define(function(require, module, exports) {})了，并且可以和 Component 社区进行一定程度的打通。CMD 格式作为调试和上线后的运行时规范继续存在，但基本上对开发者透明了，我们正在和 CMD 规范告别。 -
新的命令行工具 spm@3.x，我们将原先的功能、常用插件、和在 apm 中实践出来的通用功能都集成到一起，用于管理一个完整的模块生命周期，包括初始化，完全的本地化调试，测试，发布，构建，文档生成和部署等等功能，All in one。比起其他浏览器包管理工具，功能更加完善贴心，更浏览器，更快(网速:-D)。
-
基于 gulp 的构建工具。（spm build）
- 明显快于 grunt 方式的构建速度。
- 包管理和构建过程完全分离，源上不存放构建后的代码，发布到源上之前不再需要运行
spm build，构建只作为上线前的必要步骤。 - 简单通用的配置让你告别繁琐的 gruntfile，也不再被各种支付宝潜规则困扰。
- 支持 standalone 的打包方式，无须 Sea.js 环境也可部署使用。
- 依旧支持 css、tpl、handlebars 等特殊模块的内嵌。
-
基于 nodejs 重写的源服务 spmjs.io，用于代替原来用 python 写的 yuan，完美适配 spm@3.x，简化的账户体系支持 github 登陆和匿名两种方式，可以很方便部署（适合作为企业级开发的内网源），同时方便了我们的后续维护。我们已部署了一个 spmjs.io 作为通用的全网服务。
-
高端大气的界面以及……英文文档！我们要更加国际化。
-
大量细节变化不一一絮述。
使用
好吧，正式的用起来吧！
安装
$ npm install spm -g会覆盖 spm2，需要共存的请参考spm 2, 3 共存方案 。
确保你安装的是 3.x 版本：
$ spm -v
3.x.x开始试用
直接看官网的上手文档吧：spmjs.io/documentation
不要担心英文，这些文档都是**人写的:-D
参与
我们衷心的希望您能一起参与到新版 spm 的开发和使用中来，你可以从以下几个方面入手：
-
迁移旧的模块。
如果您在使用老的源服务 https://spmjs.org，建议进行迁移，可以参考迁移文档 和使用迁移工具。推荐参考已迁移的 Arale 模块如 Base 的结构。
-
推广 spm 社区。
由于新的模块规范通用性和开放性的改变，使我们向国外社区的推广有了可能。我们已经用
pull request的方式开始向国外的开源项目推广 spm，目前推广效果还算不错，欢迎加入我们的工作。（向开源项目推广 spm 的汇总） -
发布你的模块。
如果你有牛逼好用的前端项目，欢迎引入 spm3，把模块发布到 spmjs.io 上；也可以帮助我们发布一些业界优秀的模块（目前主要是我们团队的几个人在努力的发啊发）。因为去掉了 family，所以 spmjs.io 和 npm 一样，采用占坑的方式管理模块，好名字先到先得欢迎抢注（不要滥用哦）。
-
应用。
在您的个人博客和公司项目中使用 spm3 新方案，能用的东西才会是好东西。遇到任何问题或有什么好想法，及时给我们提建议。
备注
- 旧版的 spm2 的源服务 https://spmjs.org 将和新版的源共存一段时间（预计至少半年），强烈建议老用户进行迁移。
- 由于 spm2 和 spm3 差异巨大，如果贵公司的文档里有安装 spm2 的文档，请及时修改为
npm install spm@2.x -g。
相关链接：
管理员抢占1楼
恭喜正式发布，大家注意脚下有坑。
👍
火前占坑! 💯
强烈支持
赞! 期待内部源！
PS ： 最后的 源服务源码 的链接错了。
我靠，鄙视楼上占坑的居然没叫上我
👍
占一个坑儿，做为重庆地区唯一一个自己搭建SPM内网源的前端团队，我们之前已经踩过一个坑了，哈哈，已经提issue并得到修复
占个坑
联动Sea.js 2.3.0：seajs/seajs#1228
要搞大的节奏
怎么办，我还是不喜欢 family-name 的命名，还是喜欢 component 的 family/name
mark下学习！
http://spmjs.io 顶部导航的hover样式，请谅解强迫症患者..
火钳刘明，已经在用了，很爽。赞spm3
spm建立大生态圈了，32个赞
在spmjs.org里官方发布的包有些不是最新的，所以会出现好几个不同人维护的同名包，现在看起来会有专人负责管理更新了么？
谁占坑谁更新，和 npm 的维护机制一致。
火钳刘明
难道还能进前100？
先mark ，明天再看。
感谢你们这些踩坑的勇士。。
mark
恭喜
占位
先蹲个坑
站位，要火
Well done!
垂死病中惊坐起
占坑
留名占坑
留名
刘鸣
准备踩坑
占占
希望 http://spmjs.io/documentation 能有中文文档
http://spmjs.io/packages 页面并不友好，建议分列展示
Nice!
使用spm2也有一段时间了,也是感觉很多坑,看看spm3 如何,鸡冻中...
简洁点修改一下就好……
(BTW:Comment上传图片服务https://s3.amazonaws.com/github-cloud 也强了)
想问一下 如果我机器上有2的话 能直接运行 npm install spm -g 装3吗 2会残留啥的吗。。
@popomore 谢谢
直接覆盖，spm3说明里面有说
发自我的 iPhone5
在 2014年6月11日，19:16，zhishaofei notifications@github.com 写道：
想问一下 如果我机器上有2的话 能直接运行 npm install spm -g 装3吗 2会残留啥的吗。。
—
Reply to this email directly or view it on GitHub.
顶 👍
按照spm3的文档跑了一遍流程,确实更加与业界规范一致了.
可是我想问,开发业务模块时,应该怎么做?
我们现在是按照
https://github.com/twinstony/seajs-grunt-build
这个文档上的思路来开发的,只不过是使用spm2构建代替grunt,即开发环境与线上环境的模块路径是不一样的.
spm3把define函数去掉了,开发阶段肿么办?
开发阶段可以用 spm doc watch 会自动帮你加 define 方便本地调试。
或者打包后部署到开发环境。
或者自己实现一个简单的 server 来包裹 define ，并从开发环境重定向到本地。
这是不是太麻烦了..在这一点上,似乎spm2要好一点了
用spm3 install下来的modules，seajs是不是不能直接用？当前modules里面都没有用define包着
我明白，你的开发流程里是可以直接 seajs.use 源码（裸CMD）的，然后上线后直接切换为访问 dist 里的打包文件。
spm3 相对于 spm2 ，推荐用 CommonJS 的方式来写代码，这里差了一个将 CommonJS 转换为 CMD 格式的步骤。
目前 spm doc watch 是采用监听源文件动态 wrap define 的方式，也先推荐你尝试下这个方式。
这个问题还蛮普遍，我们现在在讨论别的解决方案，希望能提供更通用的方法。别着急
嗯,是这个问题,我们也尝试下动态包裹define.期待更好的方案
单纯模块开发
开发阶段可以用 spm doc watch 会自动帮你加 define 方便本地调试。
或者打包后部署到开发环境。
或者自己实现一个简单的 server 来包裹 define ，并从开发环境重定向到本地。
确实没有问题，但跟业务或者具体的项目连接在一起，以上的开发模式就不适用。期待更好的解决办法
spm install modules-name 安装的模块都是开发模式下的模块，这样好麻烦。例如 seajs-combo
.
|-- seajs-combo
|-- 1.0.1
|-- dist
|-- src
|-- ...
应该是这样才好
.
|-- seajs-combo
|-- 1.0.1
|-- seajs-combo.js
|-- seajs-combo-debug.js
|-- package.json
@huixisheng 理想情况下，spm3 的模块里只包含源码。seajs-combo 属于特例，因为他有自己的构建方法。
建议将spm build的核心实现独立，不要与grunt或gulp紧耦合
很喜欢CommonJS的写法，现在我们项目的模块也是使用Commonjs，提升一个档次~哈哈
Mark一个
npm 安装不成功！！！！
nodejs v0.10.29
如何不成功！！！！？
spmjs.io 里的包好乱啊，标注都不统一。
我的 spm 是 3.1.0，用 spm install seajs 安装的 seajs 是 2.3.0：
安装了 jquery 是 2.1.1，用 var $ = require('$') 获取到的 $ 为null，而直接用 require('$') 可以得到全局的 $，说明根本就没按 sea.js 规范封装嘛。
又安装了一个 alipay-storex，提示 “ReferenceError: require is not defined”，是
编码书写规范从 CMD 规范全面转向 CommonJS，更加通用和开放，不再需要书写烦人的 define(function(require, module, exports) {})了，并且可以和 Component 社区进行一定程度的打通。CMD 格式作为调试和上线后的运行时规范继续存在，但基本上对开发者透明了，我们正在和 CMD 规范告别。
spm 省事儿了，seajs 也不想着升级，简直没法用了。
没配 alias？
乱七八糟的，坑啊
------------------ 原始邮件 ------------------
发件人: "Bolt";notifications@github.com;
发送时间: 2014年7月31日(星期四) 上午10:51
收件人: "spmjs/spm"spm@noreply.github.com;
主题: Re: [spm] spm3 发布日志 (#819)
spmjs.io 里的包好乱啊，标注都不统一。
我的 spm 是 3.1.0，用 spm install seajs 安装的 seajs 是 2.3.0：
安装了 jquery 是 2.1.1，用 var $ = require('$') 获取到的 $ 为null，而直接用 require('$') 可以得到全局的 $，说明根本就没按 sea.js 规范封装嘛。
又安装了一个 alipay-storex，提示 “ReferenceError: require is not defined”，是
编码书写规范从 CMD 规范全面转向 CommonJS，更加通用和开放，不再需要书写烦人的 define(function(require, module, exports) {})了，并且可以和 Component 社区进行一定程度的打通。CMD 格式作为调试和上线后的运行时规范继续存在，但基本上对开发者透明了，我们正在和 CMD 规范告别。
spm 省事儿了，seajs 也不想着升级，简直没法用了。
—
Reply to this email directly or view it on GitHub.
我的 spm 是 3.1.0，用 spm install seajs 安装的 seajs 是 2.3.0
这有什么问题？这俩的版本又不是对应的。
安装了 jquery 是 2.1.1，用 var $ = require('$') 获取到的 $ 为null，而直接用 require('$') 可以得到全局的 $，说明根本就没按 sea.js 规范封装嘛。
你安装到的模块，都是 commonjs 规范的，所以无法直接在浏览器端运行（这不是废话吗），你需要用 spm doc watch 来进行调试模块；或使用 seajs-wrap 作为本地调试工具。发布上线时，需要进行构建（spm build）。
seajs 作为模块构建前后的 loader ，都是适用的，不需要升级。
一个标准模块的开发流程：http://spmjs.io/documentation/develop-a-package
我的 spm 是 3.1.0，用 spm install seajs 安装的 seajs 是 2.3.0：
我这里说明版本情况，不是说两个版本不统一，是为了解决问题的时候能明确是哪个版本。
你安装到的模块，都是 commonjs 规范的，所以无法直接在浏览器端运行（这不是废话吗），你需要用 spm doc watch 来进行调试；或使用 seajs-wrap 作为本地调试工具。发布上线时，需要进行构建（spm build）。
我要是不在浏览器端运行直接用 npm 就好了，干嘛要用 spm？spm 不就是为了解决浏览器端的么？
spm 遵守了 commonjs 规范，而安装的模块 sea.js 不能用，这不是打脸吗？
CommonJS 只是书写规范，模块使用前需要合并和构建，这是前端模块化的趋势。spm 并不是 seajs 的模块生态圈，而是用 CommonJS 书写的前端模块生态圈，这样我们能最大程度的复用 npm 和 component 上的现有前端模块，seajs 只是一个调试时和运行时的加载工具而已，其实我个人推荐用 standalone 的方式进行打包，这样你连 seajs 都不需要。
对于用 CommonJS 书写的模块，我们提供了一些方式用于线下调试，基本上都是动态包装 define 的方式。这时候 seajs 就发挥了它加载 CMD 模块的优势。
对于 CommonJS 规范书写的模块，想要在浏览器端进行调试和使用，无非有两种方式：
- 构建使用。（ spm build，component build 和 browerify）
- 动态包裹 define 的方式，然后用 loader 进行加载，上面我提到了 sea-wrap 和 spm doc watch ，都是类似方案。
如果希望安装的模块可以直接使用（不需要 wrap，也不需要构建），建议试试 bower ，它的规范还是比较松的，可能更适合你的场景。
去 seajs 很有必要啊，目前构建部分和 seajs 的耦合还是比较深。我觉得可以先从把 sea-modules 换个名开始，这个名字很自然地会让人把 spm 和 seajs 联系到一起。
我作为局外人，倒是觉得，你们要好好做spm，就好好做spm，让它认认真真的为 seajs 服务。
人家前端包管理工具都有好多了，你们 spm 又插一脚算啥？有啥优点？
要是真想自己做一个，倒不是把 sea-modules 换个名字，把新的 spm 换个名字呀！
利用 seajs 和 原spm 的名气推这个前端包管理工具，到头来又不支持人家 seajs，官网上也不说明白一点。
你们干脆把 CMD 和 CommonJS 的源分开吧，然后在服务端写个批量互转的插件，在任何一个源上传，都自动转换到另一个源得了。
本来就是 static package manager ，为啥就一定要为 seajs 服务。但是 seajs 是一个非常优秀的加载器，我们更愿意让它为 spm 服务。
那就去升级 seajs 去呀，让它直接可以加载 CommonJS 规范书写的模块不就好了。
。。。要是浏览器端可以这么容易直接加载 CommonJS 模块的话，也就不会出现 AMD 和 CMD 了，你可以尝试一下。
所以不是 spm 为 seajs 服务，也不能让 seajs 为 spm 服务，而是他们俩为 CMD 服务，OK？
非要 spm 抛下 seajs 去投靠 CommonJS 吗？就不能保留 CMD 版的 spm，然后给 spm 生个妹妹让它去服务 CommonJS 吗？名字什么的随便取，非抢这个 “spm” 不可？
如果有 seajs 对 CommonJS 规范的解决方案的话，就当我这些话白说。
在前端由于受浏览器限制，CMD 是一个权衡的中间方案，等到 ES6 的模块化方案被各大厂商实现后，无论是 CMD 还是 AMD 还是 CommonJS 都会是过去时。我们希望能向前看，而不是抱着 CMD 规范（况且这个规范也推广的非常不好）。
什么叫抢这个 spm 。。。。。。。。。这个讨论我们的观点已经很明确了，我觉得讨论没有必要继续下去了
或者出一个 seajs 的 node 工具，运行 sea install jquery 的时候，自动运行 “spm install jquery && spm build”，吼吼。
这个工具很简单的，@lc60005457 可以自己实现一个。
或者还有一个方式：spm build --with-deps ，会把 sea-modules 里的依赖模块也编译一遍到 dist 目录中。这样你就可以直接 use 了。
请教一下怎么引入自己开发的插件呢？另外我压缩完后，只压缩入口文件，可是我的引用的js文件都没有被压缩，是什么原因呢？
文档好赞！
请问哪里有最简单的hello spm3例子呀，没用过spm2,不知道具体如何开始，开发，调试，发布，有没有一个完整实现日常页面开发的小示例呢？
https://github.com/spmjs/docs
看下这里的文档。
大家怎么看待下面的代码，abc会被打包到一起，而不是运行时才加载
if (foo) {
require("./abc");
}
@iostalk 支持按需加载的：
if (foo) {
require(['./abc']);
}例子：https://github.com/spmjs/examples/tree/spm-webpack/load-on-demand
俺的意思可能没说清楚。。运行时加载，就是根据运行的时候foo的值，确定要不要require('abc');
if (foo) {
require('./abc');
}
而现在spm打包工具会把abc模块与当前模块打包到一起吧，这里的语义存在问题
打包在一起，但是用到 ./abc 时才会真正执行 ./abc 模块。
我已经举双手支持了！~
hen bu cuo de !
我在使用spm的时候 想把几个页面公用的文件打包成一个文件
spm里提供了两种机智来完成这个事情，一个是使用：vendor,
"vendor": ["jquery", "moment"] 是可以的
另一个是使用common:true；
但是使用common:true，在build的时候总是提示错误，
CommonChunkPlugin:while running in a normal mode ,it's not allowed to use a non-entry chunk (common.js)
不知道是不是我哪里用的不对