Publishing to Multiple Markets using @PlasmoHQ/bpp github action
Hello everyone! Hope you're doing well!
I'm having a bit of trouble on how to publish my extension to multiple markets. I currently only publish it to Chrome Webstore, but want to enable it for Firefox and eventually Edge.
I use the @PlasmoHQ/bpp, which states:
A GitHub action from Plasmo to publish your browser extension to every web store/add-ons marketplace.It then goes on to give this in the docs I wonder how the zip can be used to publish to all stores, as when you build an extension using
plasmo build it has a target, like below.
I assume that this build is only relevant for chrome and won't work in firefox or other browsers. This output is then used to generate the package, which is the ZIP. This leads me to believe the ZIP is specific to Chrome as it contains code built for a chrome-mv3 target.
Does this mean that I have to build and package the extension for each market, then specify the market specific file in the action?
Any help would be much appreciated.17 Replies
AFAIK minus different browser support for certain features that Plasmo provides, code should be the same across builds minus the effects of replacing any related environment variables (like
process.env.PLASMO_BROWSER)
So if you don't actually use any target-specific functionality or features which aren't supported across all your targets, you could probably get away with reusing the same build, but it would probably be safer to just produce a build for each platform (since you'll likely deal with something being incompatible across browsers at some point).
Here are some example GitHub workflows (from one of my extensions) for how you can go about doing that:
* Building and uploading artifacts to GitHub - build commands
* Publishing multiple artifacts from GitHub using BPP@tbrockman thanks for the info! do you happen to know how I can find out about functionality that is target specfic?
Gave +1 Rep to @tbrockman (current:
#32 - 1)And you're right, it's likely much safer to build an artifact per publish...
The thing I'm getting to now though is that I use Sentry for error monitoring and have to upload sourcemaps. If I have different builds, then I have to upload more and more sourcemaps.
I guess it's not the end of the world, but would be nice not to have to do that
probably best bet is MDN compatibility docs to check browser API support, looking through Plasmo source code for browser-specific sections (ex: https://github.com/PlasmoHQ/plasmo/blob/62e4c396bbbfad10b6e44a8f7a7e1966f2f56797/core/parcel-transformer-manifest/src/handle-sandboxes.ts#L10) , and trial and error.
could this be automated in the GitHub workflow?
Yeah, it can be. Just need to build it multiple times, upload both outputs, then package both prior to publishing
like, more than one build for each target? are the source maps produced using https://docs.plasmo.com/framework/workflows/build#with-source-maps not compatible with sentry? not too familiar with sentry or maybe misunderstood
Plasmo Docs
Create a Production Build – Plasmo
How to build a production version of your browser extension.
if you do automate it, it looks like it would help flesh out the current with-sentry example if you're interested, or you could use it as a tech blog tutorial for SEO/funneling people to your extension 😛
GitHub
examples/with-sentry at main · PlasmoHQ/examples
🔰 Example projects that demonstrate how to use the Plasmo Framework and integrate with popular tools - PlasmoHQ/examples
So yeah, let me try to break it down a bit more. Sentry is a bit confusing.
Okay, so Sentry has projects. Projects have releases. Releases have sourcemaps associated to them. In order to get the most out of Sentry, you want to
1. Create a release in your code (via tag or something)
2. Build your app
3. Create a release in sentry
4. Upload your build app's sourcemaps
5. Run your app with the release version in the
init function of sentry
This will make everything link together. The other way, which works not all of the time, is that you don't upload your sourcemaps and sentry tries to generate the release from the init and "download" your sourcemaps when the error happens.
So, when you build your app you get sourcemaps. The problem becomes that if I build my app for two targets, two sets of sourcemaps are generated.
You can see this you build for chrome then firefox and look in the directories. The cache buster inserted into filenames is different, yet they are the same app.
So, to get it work, sentry needs to know about all sourcemaps that are generated for each build/target environment.
I think it would be fine to upload all that stuff when creating the release, as you can upload them from multiple locations.
Yeah, I think I could help with that as well.
I upgrade to v8 of sentry and they make differentiations that chrome extensions should follow so they don't collide with the global namespace of the webpage (i.e. fi the website is using sentry as well, there may be some conflicts). They talk about it here.
The interesting part is that error boundaries don't really allow for custom clients (if I understood it correctly), so I had to create my own.@vernak2539 has reached level 4. GG!
🤔 that's a pretty interesting thing for them to call-out without mentioning that it only applies in the case of content scripts that are injected into the
MAIN world
The interesting part is that error boundaries don't really allow for custom clients (if I understood it correctly), so I had to create my own.seems to be the case from what I can see in their source code, that's somewhat surprising that you wouldn't just be able to do something like
client.withScope( /** your code which may throw errors **/) and have it handled automatically. or allow you to pass a client to wrap https://github.com/getsentry/sentry-javascript/blob/e31fd637c70b49eb1e08ac29e15b9b9d6e458730/packages/browser/src/helpers.ts#L43yeah... wrap is depcreated in v8 and you have to use try/catch... it was an interesting update
@tbrockman have you had any problems publishing to the Firefox add-on store? I see the links you put for your
prune repo and seems like you are publishing an addon.
But, I've come across issues that allude to problems due to source code concerns mozilla have.
I've submitted my extension to the add-on store manually for the first time and had to upload source code as well in one of the steps.GitHub
[BUG] Mozilla Firefox rejects publishing due to lack of identically...
What happened? According to https://extensionworkshop.com/documentation/publish/source-code-submission/, the new policy requires the build to be an exact match of the submitted add-on including all...
No issues with
prune, but I think that's likely because the BPP plugin doesn't publish it on Firefox with it marked as containing compiled/obfuscated source code and they don't seem to check 👀
I've had problems with another extension that I've submitted manually though, but got it accepted after submitting the build using the GitHub workflow and then including the source code with the submissions afterwardsCool thanks! I'll have a go with the new version and see what happens
Just an update here, I've ended up being able to publish it to the firefox add on store via the github action 🎉
I've not gotten the sentry stuff to work yet for FF in the github action, but that's my fault in the way of building it... so once i get the new version approved in chrome, I'll be trying again
I just got it working across edge, chrome, and firefox 🙌
@tbrockman have you had any issues with the edge store? specifically, i had the edge version created in draft mode, then had to manually publish it
Nothing like that 🤔 I've only ever had occasional issues with them taking weeks to review and publish new versions
okay, thanks! i'm having the long review times as well... so much fun ha. the chrome one is approved super quickly now