spm3 发布日志

[afc163]

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 都发生了哪些变化：

1. 精心设计的 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 字段，用于模块构建。

2. 编码书写规范从 CMD 规范全面转向 CommonJS，更加通用和开放，不再需要书写烦人的 define(function(require, module, exports) {})了，并且可以和 Component 社区进行一定程度的打通。CMD 格式作为调试和上线后的运行时规范继续存在，但基本上对开发者透明了，我们正在和 CMD 规范告别。

3. 新的命令行工具 spm@3.x，我们将原先的功能、常用插件、和在 apm 中实践出来的通用功能都集成到一起，用于管理一个完整的模块生命周期，包括初始化，完全的本地化调试，测试，发布，构建，文档生成和部署等等功能，All in one。比起其他浏览器包管理工具，功能更加完善贴心，更浏览器，更快(网速:-D)。

4. 基于 gulp 的构建工具。（spm build）

   • 明显快于 grunt 方式的构建速度。
   • 包管理和构建过程完全分离，源上不存放构建后的代码，发布到源上之前不再需要运行 spm build，构建只作为上线前的必要步骤。
   • 简单通用的配置让你告别繁琐的 gruntfile，也不再被各种支付宝潜规则困扰。
   • 支持 standalone 的打包方式，无须 Sea.js 环境也可部署使用。
   • 依旧支持 css、tpl、handlebars 等特殊模块的内嵌。

5. 基于 nodejs 重写的源服务 spmjs.io，用于代替原来用 python 写的 yuan，完美适配 spm@3.x，简化的账户体系支持 github 登陆和匿名两种方式，可以很方便部署（适合作为企业级开发的内网源），同时方便了我们的后续维护。我们已部署了一个 spmjs.io 作为通用的全网服务。

6. 高端大气的界面以及……英文文档！我们要更加国际化。

   

7. 大量细节变化不一一絮述。

使用

好吧，正式的用起来吧！

安装

$ npm install spm -g

会覆盖 spm2，需要共存的请参考spm 2, 3 共存方案 。

确保你安装的是 3.x 版本：

$ spm -v
3.x.x

开始试用

直接看官网的上手文档吧：spmjs.io/documentation

不要担心英文，这些文档都是中国人写的:-D

参与

我们衷心的希望您能一起参与到新版 spm 的开发和使用中来，你可以从以下几个方面入手：

1. 迁移旧的模块。

   如果您在使用老的源服务 https://spmjs.org，建议进行迁移，可以参考迁移文档 和使用迁移工具。推荐参考已迁移的 Arale 模块如 Base 的结构。

2. 推广 spm 社区。

   由于新的模块规范通用性和开放性的改变，使我们向国外社区的推广有了可能。我们已经用 pull request 的方式开始向国外的开源项目推广 spm，目前推广效果还算不错，欢迎加入我们的工作。（向开源项目推广 spm 的汇总）

3. 发布你的模块。

   如果你有牛逼好用的前端项目，欢迎引入 spm3，把模块发布到 spmjs.io 上；也可以帮助我们发布一些业界优秀的模块（目前主要是我们团队的几个人在努力的发啊发）。因为去掉了 family，所以 spmjs.io 和 npm 一样，采用占坑的方式管理模块，好名字先到先得欢迎抢注（不要滥用哦）。

4. 应用。

   在您的个人博客和公司项目中使用 spm3 新方案，能用的东西才会是好东西。遇到任何问题或有什么好想法，及时给我们提建议。

备注

1. 旧版的 spm2 的源服务 https://spmjs.org 将和新版的源共存一段时间（预计至少半年），强烈建议老用户进行迁移。
2. 由于 spm2 和 spm3 差异巨大，如果贵公司的文档里有安装 spm2 的文档，请及时修改为npm install spm@2.x -g。

相关链接：

• 命令行工具
• 源服务
• 文档
• 源服务源码
• spm@3.0 和 spmjs.org 的未来
• 向开源项目推广 spm 的汇总
• 迁移 spm2 到 spm3
• spm2、3共存方案

[hotoo]

管理员抢占1楼

恭喜正式发布，大家注意脚下有坑。

[sorrycc]

👍

[fengmk2]

火前占坑! 💯

[xudafeng]

强烈支持

[allenm]

赞! 期待内部源！

PS ： 最后的 源服务源码 的链接错了。

[antife-yinyue]

我靠，鄙视楼上占坑的居然没叫上我

[nightink]

👍

[youhua]

占一个坑儿，做为重庆地区唯一一个自己搭建SPM内网源的前端团队，我们之前已经踩过一个坑了，哈哈，已经提issue并得到修复

[tinys]

占个坑

[army8735]

联动Sea.js 2.3.0：seajs/seajs#1228

[bakso]

要搞大的节奏

[lepture]

怎么办，我还是不喜欢 family-name 的命名，还是喜欢 component 的 family/name

[fangge]

mark下学习！

[raffy2010]

http://spmjs.io 顶部导航的hover样式，请谅解强迫症患者..

[SMbey0nd]

火钳刘明，已经在用了，很爽。赞spm3

[tonyc726]

spm建立大生态圈了，32个赞

[seanliang]

在spmjs.org里官方发布的包有些不是最新的，所以会出现好几个不同人维护的同名包，现在看起来会有专人负责管理更新了么？

[afc163]

谁占坑谁更新，和 npm 的维护机制一致。

[JacksonTian]

火钳刘明

[dachie]

难道还能进前100？

[lwbjing]

先mark ，明天再看。

[airyland]

👍
自从开始迁移到spm@3.x,就开始了踩坑的不归路，中途提过一些 issue，不过都很快解决了。

[afc163]

感谢你们这些踩坑的勇士。。

[Adam23]

mark

[afc163]

@youhua 赞重庆地区

[afc163]

CommonJS 只是书写规范，模块使用前需要合并和构建，这是前端模块化的趋势。spm 并不是 seajs 的模块生态圈，而是用 CommonJS 书写的前端模块生态圈，这样我们能最大程度的复用 npm 和 component 上的现有前端模块，seajs 只是一个调试时和运行时的加载工具而已，其实我个人推荐用 standalone 的方式进行打包，这样你连 seajs 都不需要。

对于用 CommonJS 书写的模块，我们提供了一些方式用于线下调试，基本上都是动态包装 define 的方式。这时候 seajs 就发挥了它加载 CMD 模块的优势。

[afc163]

对于 CommonJS 规范书写的模块，想要在浏览器端进行调试和使用，无非有两种方式：

1. 构建使用。（ spm build，component build 和 browerify）
2. 动态包裹 define 的方式，然后用 loader 进行加载，上面我提到了 sea-wrap 和 spm doc watch ，都是类似方案。

如果希望安装的模块可以直接使用（不需要 wrap，也不需要构建），建议试试 bower ，它的规范还是比较松的，可能更适合你的场景。

[afc163]

看来是不是有必要去 seajs ，历史包袱还是很重。@popomore @sorrycc

[sorrycc]

去 seajs 很有必要啊，目前构建部分和 seajs 的耦合还是比较深。我觉得可以先从把 sea-modules 换个名开始，这个名字很自然地会让人把 spm 和 seajs 联系到一起。

[BoltDoggy]

我作为局外人，倒是觉得，你们要好好做spm，就好好做spm，让它认认真真的为 seajs 服务。

人家前端包管理工具都有好多了，你们 spm 又插一脚算啥？有啥优点？

要是真想自己做一个，倒不是把 sea-modules 换个名字，把新的 spm 换个名字呀！

利用 seajs 和 原spm 的名气推这个前端包管理工具，到头来又不支持人家 seajs，官网上也不说明白一点。

你们干脆把 CMD 和 CommonJS 的源分开吧，然后在服务端写个批量互转的插件，在任何一个源上传，都自动转换到另一个源得了。

[afc163]

本来就是 static package manager ，为啥就一定要为 seajs 服务。但是 seajs 是一个非常优秀的加载器，我们更愿意让它为 spm 服务。

[afc163]

先换成 spm-modules 好了。@sorrycc

[BoltDoggy]

那就去升级 seajs 去呀，让它直接可以加载 CommonJS 规范书写的模块不就好了。

[afc163]

。。。要是浏览器端可以这么容易直接加载 CommonJS 模块的话，也就不会出现 AMD 和 CMD 了，你可以尝试一下。

[BoltDoggy]

所以不是 spm 为 seajs 服务，也不能让 seajs 为 spm 服务，而是他们俩为 CMD 服务，OK？

非要 spm 抛下 seajs 去投靠 CommonJS 吗？就不能保留 CMD 版的 spm，然后给 spm 生个妹妹让它去服务 CommonJS 吗？名字什么的随便取，非抢这个 “spm” 不可？

如果有 seajs 对 CommonJS 规范的解决方案的话，就当我这些话白说。

[afc163]

在前端由于受浏览器限制，CMD 是一个权衡的中间方案，等到 ES6 的模块化方案被各大厂商实现后，无论是 CMD 还是 AMD 还是 CommonJS 都会是过去时。我们希望能向前看，而不是抱着 CMD 规范（况且这个规范也推广的非常不好）。

什么叫抢这个 spm 。。。。。。。。。这个讨论我们的观点已经很明确了，我觉得讨论没有必要继续下去了

[BoltDoggy]

或者出一个 seajs 的 node 工具，运行 sea install jquery 的时候，自动运行 “spm install jquery && spm build”，吼吼。

[afc163]

这个工具很简单的，@lc60005457 可以自己实现一个。

或者还有一个方式：spm build --with-deps ，会把 sea-modules 里的依赖模块也编译一遍到 dist 目录中。这样你就可以直接 use 了。

[liuhaifeng2005]

请教一下怎么引入自己开发的插件呢？另外我压缩完后，只压缩入口文件，可是我的引用的js文件都没有被压缩，是什么原因呢？

[ikobe-zz]

文档好赞！

[fancyboynet]

请问哪里有最简单的hello spm3例子呀，没用过spm2,不知道具体如何开始，开发，调试，发布，有没有一个完整实现日常页面开发的小示例呢？

[sorrycc]

https://github.com/spmjs/docs
看下这里的文档。

[bakso]

大家怎么看待下面的代码，abc会被打包到一起，而不是运行时才加载

if (foo) {
   require("./abc");
}

[sorrycc]

@iostalk 支持按需加载的：

if (foo) {
    require(['./abc']);
}

例子：https://github.com/spmjs/examples/tree/spm-webpack/load-on-demand

[bakso]

俺的意思可能没说清楚。。运行时加载，就是根据运行的时候foo的值，确定要不要require('abc');
if (foo) {
require('./abc');
}
而现在spm打包工具会把abc模块与当前模块打包到一起吧，这里的语义存在问题

[hotoo]

打包在一起，但是用到 ./abc 时才会真正执行 ./abc 模块。

[Coca-code]

我已经举双手支持了！~

[yangnuowei88]

hen bu cuo de !

[wpfpizicai]

我在使用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)

不知道是不是我哪里用的不对