我剛剛從使用過時的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