weixin_39519072
weixin_39519072
2020-11-23 05:52

spm 的定位思考与未来发展

在 spm 1.x 里,我们对 spm 的定位是: spm 是简单、放心的包管理工具 。spm 这三个字母代表的是 Static Package Manager.

但在实际开发过程中,从目前 spm 1.6 的功能来看,spm 涵盖了很多功能点: 1. 源服务spm server 用来搭建源服务,以存放模块及其信息。 2. 包管理spm install / upload 等功能,跟源服务配合起来,完成模块的依赖获取、下载安装、上传、部署等功能。包管理工具操作的单元是包。 3. 构建工具spm build ,主要功能是将模块源码转换成符合 Modules/Transport 规范的 dist 代码,中间还会进行预编译、压缩等操作。 4. 配置管理:对各种配置文件的管理,比如 package.json、spm/config.json、info.json 等等。目前这一块比较杂糅在一起。 5. 辅助功能:包括 spm init 等功能,nico 也可以成是 spm 体系下的文档和调试工具。

上周讨论,我们很纠结的两点: 1. Grunt 作为构建工具,目前社区非常活跃,功能也比较成熟。如果我们直接用 grunt 作为构建工具的话,Gruntfile 的理念是 程序即配置,带来的好处是非常灵活。对于个人开发者来说,使用 grunt 基本上没有实现不了的需求。 2. 但是,对于企业级开发来说,Grunt 的配置文件缺乏合理的管理方式。 目前 spm 在配置文件管理方面,比 grunt 更合适支付宝。 比如目前 spm 的配置文件,可以有继承关系,可以放在源上统一管理。这对 spm 的统一部署、升级等日常维护来说,非常方便。

或许我们可以把 spm 定位成一个静态资源管理的整体解决方案,这个方案里包括五部分: - 源服务 - 包管理 - 构建 - 配置管理 - 辅助功能 1. 源服务 目前没有合适成熟的开源类库,因此这一块我们还是得自己做。南伯正在开发的 yuan 可以继续往前推进。 2. 包管理 目前 yeoman、ender 等有做,但和我们的理念上存在较大差异,很难复用起来。 3. 构建工具 目前是最百花齐放的,grunt 是其中的姣姣者。这一块我们或许真的可以不用重复造轮子,或许应该反过来给 grunt 提交我们社区的 tasks. 4. 配置管理 是 spm 目前的一个特色,借鉴了很多 maven 的优秀思想。这一块目前的难点是是否可以独立出来?比如可以统一管理 package.json、Gruntfile 等配置管理,让这些配置文件也都可以继承、统一部署更新等。如果能做到,就能解决我们目前在支付宝遇到的问题。 5. 辅助功能 也不叫辅助功能,这一块想得不是很清楚,更多的应该是一种扩展机制,涵盖文档生成、调试辅助、测试驱动等等,可想象的空间很大。以后再逐一来集成。

如果大家同意上面的功能拆分,那么接下来我们要做的事情是: 1. spm 1.x 的拆分。着重拆分出 构建工具配置管理 两部分。配置管理可以独立做,构建工具具体怎么做,是否换成 grunt,我的建议是年前让大家都用用 grunt,真实去用才能有真感受。等年后来决定构建工具的进一步发展。 2. spm2 的进一步开发。这部分工作,着重在 包管理 上。build_core 部分,尽可能多的 focus 在 SDK 层面。这样,无论以后单独做,还是成为 grunt 的一个 task,都能省不少工作量。 3. 源的发展。南伯继续。这周先把规范、接口等晒出来。综合起来考虑,尽量能做成开放式架构。 4. 辅助功能。先按兵不动。有时间时,可以试着去用用 Yeoman 等套件,Yeoman 还是挺不错的,啥都做呀。

可继续讨论。春节前达成一致。

该提问来源于开源项目:spmjs/spm

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

29条回答

  • weixin_39829166 weixin_39829166 4月前

    spm 这一块的设计和实现一直是基于通用的静态资源管理方案来做,并以支付宝的实际情况进行检验,从而努力做到可定制和易扩展。

    未来的 spm2 以及对应的源服务也会是一个基于 cmd 模块规范和源服务规范的项目,内部的需求会用各种插件来实现。这一块的规划和设计还在不停的 PK 中,也欢迎您的参与。

    点赞 评论 复制链接分享
  • weixin_39860975 weixin_39860975 4月前

    觉得首先在这之前可以让大家同步spm的确切定位,是seajs的配套,还是spm有一个built-in task可以处理seajs的构建,这一个点需要让其他开发者明确。

    点赞 评论 复制链接分享
  • weixin_39519072 weixin_39519072 4月前

    感谢各位的参与讨论,特别是 的,很值得思考。

    点赞 评论 复制链接分享
  • weixin_39716703 weixin_39716703 4月前

    spm 的定位应该是 package manager,也就是说 spm 应该是一个更像 npm 的东西,而不是一个像 grunt 或者 maven 的东西。虽然构建是其中重要的一环,但是定位一定不是构建。

    cc

    点赞 评论 复制链接分享
  • weixin_39956558 weixin_39956558 4月前

    很期待纯build的spm。。。

    点赞 评论 复制链接分享
  • weixin_39716703 weixin_39716703 4月前

    spm 不会是纯 build 的,如果你用 grunt 的话,可尝试 https://github.com/spmjs/grunt-spm-build

    点赞 评论 复制链接分享
  • weixin_39716703 weixin_39716703 4月前

    see demo case: https://github.com/spmjs/grunt-spm-build/tree/master/test/cases/relative

    点赞 评论 复制链接分享
  • weixin_39956558 weixin_39956558 4月前

    thanks. I will try this.

    点赞 评论 复制链接分享
  • weixin_39716703 weixin_39716703 4月前

    目前还是 alpha,将会是 spm2 的一个子集。另外,你还可以自己实现一个 build,最麻烦的地方已经帮你处理好了,详见 https://github.com/spmjs/cmd-util

    点赞 评论 复制链接分享
  • weixin_39956558 weixin_39956558 4月前

    大概看了一下,确实是比spm精简好多,而且cmd-util也非常专一。另外,貌似concat只是将相关的依赖进行合并,并没有对模块的id进行处理?不知道你是否有计划实现build,因为看代码刚提交没多久:)

    点赞 评论 复制链接分享
  • weixin_39716703 weixin_39716703 4月前

    grunt-spm-build,已实现 build。是刚完成的,文档还没有,建议先看看代码。

    build 分为: 1. spm-transport: 这一步就会生成有 id 和 dependencies 的 js 文件 2. spm-concat 3. spm-beautify, spm-css-minify, spm-js-minify 4. clean

    点赞 评论 复制链接分享
  • weixin_39956558 weixin_39956558 4月前

    十分感谢你的帮助~仔细看了一下,确实不错~赞一个先。

    不过不知道为什么,总感觉现在的seajs模块合并工具让我用的时候都感觉太过于繁杂。很想要一个工具,像seajs那样简单,只要配置好config,然后直接seajs.use(当然这里只是说明,其实工具应该是build)就直接帮我把所有的依赖全部transport、concat、minify等。。。

    点赞 评论 复制链接分享
  • weixin_39716703 weixin_39716703 4月前

    理论上来说,是会做成这样子的,这个在 spm2 中完成。 grunt-spm-build 只是一个基于 grunt 的 task 集合,目标是各个 task 职责清晰。

    这里说明一下: - cmd-util 是为开发者写的(不是为普通使用者所写),同时用于服务 spm2 - grunt-spm-build 是为了解 grunt,并且希望了解 build 的各个步骤的人所写的,同时服务于 spm2

    也就是说,这些都是中间产物,可用,但并不适合最终用户。请等待 spm2。

    点赞 评论 复制链接分享
  • weixin_39821189 weixin_39821189 4月前

    我一直以为spm是seajs packages manager的简写,也只是单纯的想用seajs才来了解并学习spm的。但在使用过程中,遇到了很多麻烦,资料匮乏,问题蹊跷等,确实也是因为还没搞明白其中的原理吧,但我真的尽力在学了。 我只是想把已经应用seajs的项目部署下,达到当时使用seajs的初衷:减少http请求,管理依赖,仅此。

    点赞 评论 复制链接分享
  • weixin_39929566 weixin_39929566 4月前

    目前 spm 主要提供了一个整体的解决方案,不仅包括打包,也包括了配置管理等很多内容,这些功能的使用都是基于一些约定来完成的,也就是说如果按照我们提前约定的形式来使用的话,其实很简单(hello spm)。 但是每个公司由于业务背景和使用习惯的不同可能无法完全按照预定的形式来使用,而 spm 本身也希望能兼容一部分这些用户,但是随着用户各种需求层出不穷也造成了 spm 的一些膨胀,所以不仅增加了复杂度,对于本身的持续扩展也造成了一些问题,所以我们推出了 spm2, 这个版本会很灵活也很基础。用户对于自己的需求可以自己定制。所以如果只是希望简单的打包合并可以去看下 http://docs.spmjs.org/en/

    点赞 评论 复制链接分享
  • weixin_39882589 weixin_39882589 4月前

    SPM改名为Static Package Manager,这个感觉很难改过来,大家都已经熟悉了SeaJs Package Manager,就是改了大家也不愿意认可,就像学过拼音在学英语单词,会有抑制作用的,观念比较难改变,我建议干脆改一个名字吧,别用缩写了,纯属个人意见。

    我感觉spm的发展方向和bower, ender, volo, component, jamjs之类的应该差不多,不知道spm2的整体流程是怎么样的,我们好参考学习下,这个是我们正在做的 kissygalleryteam/KPM#1。

    点赞 评论 复制链接分享
  • weixin_39519072 weixin_39519072 4月前

    spm2 的定位目前调整为纯标准 CMD 模块的 build + 包管理工具

    具体可以看这里:http://spmjs.github.com/spm2/en/

    点赞 评论 复制链接分享
  • weixin_39716703 weixin_39716703 4月前

    http://docs.spmjs.org

    点赞 评论 复制链接分享
  • weixin_39789979 weixin_39789979 4月前

    还是喜欢 SeaJs Package Manager。Spm 和 Seajs 两个在一起的结局更让人期待啊。

    点赞 评论 复制链接分享
  • weixin_39690625 weixin_39690625 4月前

    纯标准 CMD 模块的 build 包管理工具

    这两个会独立 npm install 么?

    点赞 评论 复制链接分享
  • weixin_39716703 weixin_39716703 4月前

    为解析和 build 所写的库:

    spmjs/cmd-util

    spmjs/spm2 依赖这两个库。

    点赞 评论 复制链接分享
  • weixin_39989668 weixin_39989668 4月前

    npm太复杂了,看了两天没有搞懂怎么用的,光那个package.json弄的我都头大,怎么配置都好像不听话的样子。我觉得只需要配置项目名、根目录和版本号即可,其他则分析代码将其压缩、加入ID即可。

    点赞 评论 复制链接分享
  • weixin_39849762 weixin_39849762 4月前

    发现 几个月前的回复

    点赞 评论 复制链接分享
  • weixin_39829166 weixin_39829166 4月前

    人家看不下去了,亲自来贵团队拯救你们。

    点赞 评论 复制链接分享
  • weixin_39713833 weixin_39713833 4月前

    这都被你们翻出来了呃。。。是啊,看不下去了所以亲自来了,可来了发现,一是即使人来了,我也帮不上spm 2什么忙,因为好复杂看不懂;二是当用了这一整套工具后,才觉得这也许是Arale 目前最合适的方式。可如果这套东西搬到其他公司,或者其他开发者用,可能并不是最合适的方式。

    点赞 评论 复制链接分享
  • weixin_39690625 weixin_39690625 4月前

    我使用 spm 最最重要的原因,是它是 SeaJS 的配套,build 时能够分析依赖,处理 id。我目前还在用 v0.9.11,之前试着切换到最新版,可是报错,因为没时间折腾,就放弃了,想等 2.0 时再看。

    坊间好多声音都说 spm 难用,我脚得是它跟支付宝耦合太紧了。

    我很赞成拆分,各功能都可独立使用最好。很多人觉得用了 SeaJS 就必须使用 spm,别让 spm 拖累 SeaJS。

    点赞 评论 复制链接分享
  • weixin_39713833 weixin_39713833 4月前

    同意 的观点.

    我用spm 完全是因为用了seajs, 代码build时可以分析依赖等功能. 后来spm升级, 总觉得好复杂, 对于我们这种小项目来说... 而且xx.json的配置文件好多~ 搞不懂哈. 所以之前尝试了下新版本最终还是放弃了, 还是用旧版的就已经满足我小小需求了. 哈哈. 我要求不多, 就是想简单, 省心.

    点赞 评论 复制链接分享
  • weixin_39778400 weixin_39778400 4月前

    作为一个开源库的辅助工具,无论开源库升级到什么版本,辅助工具本身不应该被复杂化,它承载的功能就是帮助使用者简单快速有效地使用、部署和安装,如果上手不易会让使用者产生恐惧感。

    点赞 评论 复制链接分享
  • weixin_39860636 weixin_39860636 4月前

    一起都以支付宝来考虑,那我们就不考虑了

    点赞 评论 复制链接分享