|
|
|
|
|
by dotproto
1589 days ago
|
|
Hey, Simeon from the Chrome Extensions team here. A lot of other replies talk about libraries and tools; I'd like to focus more on some general guidance. First up, no, you don't need to maintain two completely different code bases. I'd recommend having a separate manifest.json for each browser or having a build step generate the per-browser manifest.json. A lot of the manifest changes are relatively small, like splitting "host_permissions" out from "permissions" and should be automatable. For example, a build step would merge these two arrays for the MV2 manifest. As for your background scripts, if possible I'd recommend limiting the JS capabilities you use to the intersection of what all browsers support. - Chrome supports background service workers
- Safari supports event pages and I believe has service worker support in beta builds of their OSs
- Firefox supports persistent background pages In other words, target the capabilities available in both worker and page contexts. You'll also want to design your background logic to embrace ephemerality. This is required by Chrome, but it also benefits Firefox users in that it helps keep the browser responsive. Best of luck! |
|
It isn't a horrible workaround, but I will need to update code in two places every time I want to make a change, and that is bad developer experience, bad for timely updates, bad for being able to support a user regardless of the browser they use. I don't care what they use, I just want them to be able to use my tool. But as far as I can tell, the whole ecosystem for developing and publishing browser extensions is quite behind, at least as compared to the rest of the things I work on.
I appreciate your general guidance, and accept that this simply isn't the best state of things to work with.