Firefox 38.0 开始支持用性能更好的 JPM 来打包扩展

原来打包扩展使用的是 Python 语言写的 CFX 命令行工具，这对于用 Add-on SDK 写扩展的开发者来说很熟悉，现在从 Firefox 38.0 开始支持用 JPM 来打包扩展并上传到 AMO，Firefox 也计划停止对 CFX 工具的更新。

JPM 是基于性能更好的 Node.js，也就是基于 JavaScript，这是趋势，尤其是 JS 的性能有了突飞猛进的提升。JPM 的优势主要有：
JPM 便于安装，尤其是在 Win 平台；
JPM 便于发布，支持使用 NPM 打包的形式发布，NPM 是专为 JS 而生的包裹管理器，而 CFX 分发是zip格式。
JPM 打包后的体积更小，不产生多余文件

当然，CFX 打包的扩展依然可以上传，Firefox 会继续支持，但推荐使用 JPM。注意：JPM 打包方法必须是 Firefox 38 和以上版本才可使用。

JPM Replaces CFX For Firefox 38

cfx 最低支持到 firefox 22
支持更老的 firefox 版本的扩展需要旧版 cfx 打包
但是 amo 不接受提交旧版 cfx 打包
cfx 已经一年多不接受任何补丁了
根本就是拒绝更新
很多功能都缺失
相信 mozilla 也很快会整个砍掉 cfx

jpm 0.0.25 以后版本只支持 firefox 38 及以上
要支持 38 以下版本必须回滚到 jpm 0.0.23

顺手再黑一下 jpm

JPM is easier to install, especially on Windows.
cfx 同样很好安装

JPM is easier to release, because CFX is Python based and is distributed as a zip file. JPM is Node-js based and is distributed through NPM.
cfx 完全可以通过 python 的包管理工具 pip 来分发
mozilla 自己的 moz* 系包就是如此
只是 cfx 不愿意（或者干脆说，addon sdk 小组的成员熟悉 javascript，但是不熟 python）这样而已

JPM produces smaller XPIs, because no extra files are produced*.
结果这个特性是由 firefox 自己提供的
所以 cfx 也一样可以做到
但是 addon sdk 小组拒绝更新 cfx，也拒绝接受别人对 cfx 贡献的功能补丁 lol

JPM supports NPM packges.
npm 的坑也不少，早晚要埋掉一堆人

aaaa007cn：cfx 最低支持到 firefox 22
支持更老的 firefox 版本的扩展需要旧版 cfx 打包
但是 amo 不接受提交旧版 cfx 打包
cfx 已经一年多不接受任何补丁了
根本就是拒绝更新
很多功能都缺失
相信 mozilla ...回到原帖

原来如此啊，怪不得还是用过的人才有发言权啊，mozilla想推jpm而已吧

nodejs 真流行啊。 python 不及了

不过就 nodejs 和 python 的包管理方式来讲。还是 nodejs 更好一点。
nodejs 的 repos 自己搭很简单。 python 就复杂了，而且PyPI 的界面太简陋了，好多年没改进了。最近 python.org 首页都改版了, PyPI 还是老样子。
包依赖上 python 也显得复杂，python 写个打包配置，学习曲线也比 nodejs 高。
python 安装依赖包直接上 global，很容易遇到依赖冲突，python 的 local 模式只能绕道 virtualenv。
nodejs 安装依赖包默认就是 local 模式。
不管怎么说 python 不进则退，新的打包工具性能不好说更好。
但是开发环境肯定是变得更友好，这是 Mozilla Developer 的选择。更友好的开发环境能提高开发效率。
nodejs 支持回调，事件驱动，并发这些特性，都是 python 所欠缺的，在 IO 的处理效率上就已经比 python 高了。所以说效率更高也不是吹牛。
看起来很早就做出决定换 nodejs 的决定了，既然决定肯定就不会再费力气维护 python 的工具了。毕竟人手有限。
作为用户，大家就只有跟随了。不管用什么语言开发，功能应该还是一样的。
所以整体也是往好的方向走。

fang5566：原来如此啊，怪不得还是用过的人才有发言权啊，mozilla想推jpm而已吧回到原帖

推 jpm 不是问题
问题是作为替代的 jpm 得有相应的完成度啊
放弃开发多年的已经比较成熟的 cfx
从头开发的 jpm 到现在还只是个半成品
实在无法让人认同

fiag：nodejs 真流行啊。 python 不及了

不过就 nodejs 和 python 的包管理方式来讲。还是 nodejs 更好一点。
nodejs 的 repos 自己搭很简单。 python 就复杂了，而且PyPI 的界面太简...回到原帖

所有包管理工具都各有优缺点
哪种更好，见仁见智，也要根据使用场合来看
pip 有 pip 的问题，npm 也有 npm 自己的毛病
你觉得 pip 学习曲线比 npm 高
我却倾向于把这种门槛看作一个过滤器

全局 vs local 要看场合，但这和使用 addon sdk 没啥关系

语言特性也一样要看场合
回调就是 promise 出现的直接原因
jpm 就大量使用了 promise 来回避回调地狱（配合 npm 的设计，也直接导致 modules 中有不少 promise 系的依赖重复出现 lol）
事件驱动，并发 python 也有
io 效率高？可是 issues 中曾有人抱怨 jpm 生成 xpi 速度比 python 慢多了

开发效率高那肯定
毕竟 addon sdk 开发小组是 javascript 专家而不太熟悉 python

没错用 python 开发还是 nodejs 开发都和最终用户没有太大关系
可问题是现在 jpm 完成度实在是太低了

官方拒绝接受社区提交的 cfx 补丁使得有些扩展开发者转而自己去维护自己的 cfx 分支了

aaaa007cn：所有包管理工具都各有优缺点
哪种更好，见仁见智，也要根据使用场合来看
pip 有 pip 的问题，npm 也有 npm 自己的毛病
你觉得 pip 学习曲线比 npm 高
我却倾向于把这种门槛看作一个过滤器

全局 vs loc...回到原帖

promise到底是干嘛使的 初衷是什么

pcxfirefox：promise到底是干嘛使的 初衷是什么回到原帖

简单地说
就是为了避免直接手写反人类的异步、回调

https://www.promisejs.org/

https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Promise
https://promisesaplus.com/

aaaa007cn：简单地说
就是为了避免直接手写反人类的异步、回调

https://www.promisejs.org/

https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global...回到原帖

哦 也就是说把Firefox的promise模块精简掉会导致很多问题

pcxfirefox：哦 也就是说把Firefox的promise模块精简掉会导致很多问题回到原帖

大部分（或者全部？）用 javascript 实现的异步操作都依赖 promise.jsm

https://github.com/mozilla/jpm/issues/279
jpm 还是准备出 zip 包来分发了 lol

aaaa007cn：https://github.com/mozilla/jpm/issues/279
jpm 还是准备出 zip 包来分发了 lol回到原帖

因为那个npm分发方式不常见。

aaaa007cn：大部分（或者全部？）用 javascript 实现的异步操作都依赖 promise.jsm回到原帖

那我明白了 精简时注意一下