Skip to content
This repository has been archived by the owner on Aug 15, 2018. It is now read-only.

spm3 发布日志 #819

Closed
afc163 opened this issue Jun 10, 2014 · 91 comments
Closed

spm3 发布日志 #819

afc163 opened this issue Jun 10, 2014 · 91 comments

Comments

@afc163
Copy link
Member

afc163 commented Jun 10, 2014

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

相关链接:

@hotoo
Copy link
Member

hotoo commented Jun 10, 2014

管理员抢占1楼

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

@sorrycc
Copy link
Member

sorrycc commented Jun 10, 2014

👍

@fengmk2
Copy link
Contributor

fengmk2 commented Jun 10, 2014

火前占坑! 💯

@xudafeng
Copy link

强烈支持

@allenm
Copy link

allenm commented Jun 10, 2014

赞! 期待内部源!

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

@antife-yinyue
Copy link

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

@nightink
Copy link

👍

@youhua
Copy link

youhua commented Jun 10, 2014

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

@tinys
Copy link

tinys commented Jun 10, 2014

占个坑

@army8735
Copy link
Member

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

@bakso
Copy link

bakso commented Jun 10, 2014

要搞大的节奏

@lepture
Copy link
Contributor

lepture commented Jun 10, 2014

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

@fangge
Copy link

fangge commented Jun 10, 2014

mark下学习!

@raffy2010
Copy link

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

@SMbey0nd
Copy link

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

@tonyc726
Copy link

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

@seanliang
Copy link

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

@afc163
Copy link
Member Author

afc163 commented Jun 10, 2014

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

@JacksonTian
Copy link

火钳刘明

@dachie
Copy link

dachie commented Jun 10, 2014

难道还能进前100?

@lwbjing
Copy link

lwbjing commented Jun 10, 2014

先mark ,明天再看。

@airyland
Copy link

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

@afc163
Copy link
Member Author

afc163 commented Jun 10, 2014

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

@Adam23
Copy link

Adam23 commented Jun 10, 2014

mark

@afc163 afc163 modified the milestone: 3.0 Jun 10, 2014
@afc163
Copy link
Member Author

afc163 commented Jun 10, 2014

@youhua 赞重庆地区

@afc163
Copy link
Member Author

afc163 commented Jul 31, 2014

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

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

@afc163
Copy link
Member Author

afc163 commented Jul 31, 2014

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

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

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

@afc163
Copy link
Member Author

afc163 commented Jul 31, 2014

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

@sorrycc
Copy link
Member

sorrycc commented Jul 31, 2014

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

@BoltDoggy
Copy link

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

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

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

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

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

@afc163
Copy link
Member Author

afc163 commented Jul 31, 2014

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

@afc163
Copy link
Member Author

afc163 commented Jul 31, 2014

先换成 spm-modules 好了。@sorrycc

@BoltDoggy
Copy link

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

@afc163
Copy link
Member Author

afc163 commented Jul 31, 2014

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

@BoltDoggy
Copy link

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

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

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

@afc163
Copy link
Member Author

afc163 commented Jul 31, 2014

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

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

@BoltDoggy
Copy link

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

@afc163
Copy link
Member Author

afc163 commented Jul 31, 2014

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

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

@liuhaifeng2005
Copy link

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

@ikobe-zz
Copy link
Member

文档好赞!

@fancyboynet
Copy link

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

@sorrycc
Copy link
Member

sorrycc commented May 14, 2015

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

@bakso
Copy link

bakso commented May 14, 2015

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

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

@sorrycc
Copy link
Member

sorrycc commented May 14, 2015

@iostalk 支持按需加载的:

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

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

@bakso
Copy link

bakso commented May 19, 2015

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

@hotoo
Copy link
Member

hotoo commented May 19, 2015

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

@Coca-code
Copy link

我已经举双手支持了!~

@yangnuowei88
Copy link

hen bu cuo de !

@wpfpizicai
Copy link

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

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests