我刚刚从使用过时的cfx切换到jpm来开发我的Firefox附加组件。每次我对代码进行更改并想再次测试时，我都必须使用＆＃34; jpm run＆＃34;命令它需要3到5分钟来启动浏览器内部的新代码。这使得开发我的插件几乎是不可能的，因为每次我想测试新的代码行时，我都要等几分钟。
这种问题在Chrome中并不存在，所以我不确定Mozilla的人在想什么。他们是否想要为浏览器开发插件几乎是不可能的？
其他Firefox附加组件开发人员在测试代码时做了些什么？他们只是花了几个小时启动并非常缓慢地重新启动浏览器？或者有解决方法吗？
答案 0 :(得分：0)
您可以将jpm watchpost与扩展程序自动安装程序一起使用，以便在正在运行的firefox会话中自动重新加载扩展程序。
但即使没有它，也不应该花费几分钟，只需几秒钟。
答案 1 :(得分：0)
作为the8472 has mentioned，您可以使用without the need to restart the browser using jpm测试加载项SDK扩展jpm watchpost。使用它似乎需要一些配置。我没有使用过这个，因为我会发现每次写入文件时插件都会自动更新有点烦人。我经常更改多个文件，或者在运行加载项以进行测试之间对同一文件进行多次写入。基本上，我希望更多地控制加载项的重新加载时间，而不是每次更改文件时自动完成加载项。
有一种方法可以加载temporary add-ons，它适用于解压缩的附加组件和 .xpi 文件。问题是在运行jpm之前，您的加载项实际上并不是一个完整的Firefox加载项。 jpm为您的加载项的内容添加包装器，使其成为normal bootstrapped add-on。如果没有这些包装器，您的加载项将无法运行。一种可能性是每次要测试新版本时运行jpm xpi：一旦最初将加载项作为临时加载项加载，您将运行jpm xpi，然后单击about:debugging中的加载项“重新加载”按钮。
[此方法将遇到需要解决的问题]：或者，您可以解压缩 .xpi 文件，并在使用临时文件时从结果目录中包含的文件继续开发安装附加组件的附加方法（单击解压缩文件的目录中的任何文件作为临时附加组件安装）。但是，此方法可能会阻止您对加载项使用jpm。此外，jpm在将加载项打包到 .xpi 文件时执行的操作会有所不同，具体取决于加载项的内容。如果是这样，如果您显着更改了加载项的功能（例如 package.json 中的更改不会传播到 install.rdf ），事情可能会开始中断。使用此方法时，如果要发布附加组件，可能需要使用"normal", non-jpm method of creating an .xpi file。