我刚刚从使用过时的cfx转换为jpm来开发我的Firefox附加组件。每次我对代码进行更改并想再次测试时，我都必须使用“jpm run”命令，它需要3到5分钟的时间才能启动浏览器并使用新代码。这使得开发我的插件几乎是不可能的，因为每次我想测试一个新的代码行时，我都必须等待几分钟。JPM Run的测试非常慢
这种问题在Chrome中不会发生，所以我不确定Mozilla的用户在想什么。他们想让它几乎不可能为他们的浏览器开发插件吗？
其他Firefox插件开发人员在测试他们的代码时做了些什么？他们是否花了数小时启动并非常缓慢地重新启动浏览器？还是有解决方法？
您可以使用jpm watchpost和扩展自动安装程序，而不是在运行的Firefox会话中自动重新加载扩展。
但即使没有，它不应该需要几分钟，只有几秒钟。
刚刚尝试过这与jpm post --post-url http：// localhost：8888 /但我得到一个ECONNREFUSED错误。任何想法为什么？ – user1850261
作为the8472 has mentioned，您可以使用jpm watchpost测试附加SDK扩展without the need to restart the browser using jpm。使用这似乎需要一些配置。我没有用过这个，因为我发现在每次写入文件时都会自动更新插件，这有点烦人。我经常更换多个文件，或者在运行插件测试的时间之间对同一文件进行多次写入。基本上，我想保持更多的控制，以便何时重新加载插件，而不是在每次更改文件时自动完成插件。
有一种方法可以加载temporary add-ons，它适用于两个解包的加载项和.xpi文件。问题是，在运行jpm之前，你的加载项实际上并不是一个完整的Firefox加载项。 jpm为您的加载项的内容添加包装，使其成为normal bootstrapped add-on。没有这些包装，你的插件就无法运行。一种可能性是每次要测试新版本时运行jpm xpi：一旦您最初将附加组件加载为临时附加组件，您将运行jpm xpi，然后单击附加组件的“重新加载”按钮，在about:debugging。
[此方法存在您需要解决的问题]：或者，您可以解压缩文件并使用临时附加方法从包含在生成的目录中的文件继续开发安装您的加载项（单击解压文件以作为临时加载项安装的目录中的任何文件）。但是，此方法可能会阻止您根据您的加载项使用jpm。此外，jpm在将您的加载项打包到.xpi文件时会执行稍微不同的操作，具体取决于加载项的内容。如果是这样，如果您显着更改附加功能（例如，package.json不会传播到install.rdf），则事情可能会开始中断。用这种方法，当你想发布你的加载项时，你可能需要使用"normal", non-jpm method of creating an .xpi file。
使用'jpm run'启动Firefox和一个最小插件对我来说只需不到10秒（刚刚测试过）。你的插件有多大？你使用的是什么版本的“jpm --version”？您使用的是哪个版本的Firefox？需要更多信息（例如，机器类型，操作系统等）。 – Makyen
我通过删除我的加载项文件夹中的一些文件（它就像50MB），将其降低到30秒以下。我在那里有一些XPI文件的副本，这可能会降低速度。仍然非常烦人，我不得不每次重新启动浏览器。 我正在使用Firefox开发者版，并且确实应该是一种方式，只是在Chrome中加载未打包的加载项。当我在Chrome中开发时，我只需访问chrome：\\ extensions页面并刷新以查看我的最新版本。 – user1850261