Support manifest v3 for web extensions

[robarnold]

🙋 feature request

Chrome (and Edge) support a newer version of the extension manifest, v3 but the webextension config plugin only supports version 2. The two are very similar, but some of the fields that name resources are different.

🤔 Expected Behavior

The @parcel/config-webextension package should support extensions that are defined with v3 of the manifests (i.e. point parcel at the manifest.json and let it package things up).

😯 Current Behavior

Currently when following the Web Extension recipe and using a v3 manifest, parcel build throws an error:

@parcel/transformer-webextension: Invalid Web Extension manifest
/path/to/my/extension/manifest.json:5:23
  4 |   "version": "1.0",
> 5 |   "manifest_version": 3,
>   |                       ^ Possible values: "2"
  6 |   "action": {
  7 |     "default_popup": "popup.html"

💁 Possible Solution

From parcel's point of view, the manifests are fairly similar.

• The schema check needs to allow version 3
• The new background.service_worker property
• The CSP setting has changed from being a simple string so the HMR logic will need to be modified to rewrite multiple policies instead of just one.
• The actions, which can refer to resources, have moved under a new toplevel key
• The schema for web_accessible_resources changed slightly
• There are additional restrictions on how code is executed and I do not know how this affects the bundles and HMR code for Parcel.

🔦 Context

Chrome is pushing this as the new way to write extensions and has removed much of the v2 documentation in favor of pushing v3 by default. A big architecture change for extensions seems to be the move to using service workers + message passing instead of a background page. I am starting to write a new extension (not having done so before), so I am trying to follow the documentation on the Chrome site and set this project up for having the right long-term architecture, so following the v3 manifest feels like the best course, rather than creating a v2 manifest.

💻 Examples

There don't seem to be many official examples yet - even the official repo has a limited selection.

[101arrowz]

Thanks for creating a list of differences; I'll try to add v3 support to the transformer in a few days.

[Darhagonable]

I'm also in a position were this is an issue. Any idea when the v3 support might be added?

[101arrowz]

I've been busy of late, but I should be able to get to this on the weekend.

[101arrowz]

I've run into a problem: the hack used to enable HMR in content scripts is no longer possible.

In addition, MV3 disallows certain CSP modifications for extension_pages that were permitted in MV2. The script-src, object-src, and worker-src directives may only have the following values:

• self
• none
• Any localhost source, (http://localhost, http://127.0.0.1, or any port on those domains)

We need unsafe-eval so that new Function(newCode) can be used in the HMR code. This is a serious problem: one of the key benefits of the WebExtension transformer over not using a bundler at all is HMR. Is there any workaround?

[Darhagonable]

I think I would like the support for v3 even without HMR. A workaround for HMR could be figured out after the fact if possible.

[Darhagonable]

Someone seem to have got hot reloading working with webpack with manifest v3
chrome-extension-boilerplate-react | officially migrated to manifest v3
maybe this could be of help somehow?

[101arrowz]

I don't think they did anything to account for the lack of permissions in V3. At runtime, the HMR will probably throw an error about unsafe-eval being violated. I'll implement V3 without HMR, but it will take at least another week.

[Darhagonable]

Any updates on this? @101arrowz

[101arrowz]

Sorry I've been swamped over the last few months and don't know if I'll be able to get to this anytime soon...anyone else can feel free to take the lead on this.

[AntonOfTheWoods]

I spent a while trying to get this set up for local testing and it is a perfect example of why we need tools like parcel and why "modern JS" drives so many people absolutely insane! The code turns out to be very tightly coupled to the build config environment. Fine if there was only a couple (so you could learn them) but in JS there are probably hundreds, and tens of widely used ones.

All this because I got sick of CRA being broken, using obsolete deps and making totally unjustified (and unchangeable) assumptions, so I look for something else. Great, parcel looks awesome and fast. It doesn't support manifest v3 and the maintainer doesn't have time to upgrade. "I should be able to fix that, the differences are very small (except hot reloading)". No, ,you fool, you won't, not without spending days trying to understand some totally obscure build process...

[stefanbuck]

@AntonOfTheWoods Please use your wisdom and time to help us getting this fixed rather than ranting about the js community

[AntonOfTheWoods]

I would love to @stefanbuck but I can't see how I can do anything more than I have currently, which is a nasty local hack that implements the features of V3 that I need. I would love to be able to contribute but it is very frustrating that the bar for entry to contribute meaningful code is always protected by hours and hours of understanding build config...

[fregante]

Update: https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/

• New v2 extensions will no longer be accepted in 3 months (2022)
• Updates to existing v2 extensions are allowed until the end of 2022

[101arrowz]

Well if this transformer is going to be basically useless in 3 months, I guess I'll try again to update it; can't make any promises on timing though.

P.S. Can someone with more knowledge about the situation explain to me why they're doing this? Or is it just another instance of Google steamrolling their new ideas into standards? It doesn't look like Firefox is updating for any reason other than to stay compatible with Chrome.

[fregante]

Many of the features don't seem to require a whole new manifest on their own, but given that they want to make several breaking changes (service worker as background page, no eval, more specific settings and rules, …) it kinda makes sense. The controversy was also around the possibility of reduced adblocking capabilities, but that's another story…

[101arrowz]

I've gotten a preliminary implementation set up. I'm pretty sure HMR is completely broken (even refreshing the page doesn't update the extension) but it supports MV3, will create a PR in a few days.

[Darhagonable]

We can create separate issue for HMR for web extensions after the PR gets merged.

For the sake of documentation I'll just throw this in here since we don't have the separate issue for it yet:
Did some more looking into if any others have found workarounds to have hot reloading work with manifest v3 and found these that seems to be solutions done for webpack if it might be of any use for us:
https://github.com/pacexy/mv3-hot-reload
https://github.com/sidehustlelab/chrome-manifest-v3-webpack-hotreload-template

and this from a Chrome Extensions DevRel https://groups.google.com/a/chromium.org/g/chromium-extensions/c/pYtdXH0f46E/m/2TjJ3MWVBwAJ

I have yet to test these myself but thought it might be worth linking to in case someone wanna follow up on hot reloading in the future.

[101arrowz]

Draft PR #7050 is open, please feel free to test this on your own MV3 extensions by following the guidelines in CONTRIBUTING.md. I have only tested this on a MV2 extension I've ported to MV3 so I don't know if this actually works properly for all cases.

[hyusetiawan]

hey all, i wonder if this is still being actively worked on? I see that v2 manifest is being deprecated real soon and the only public option for parcel is the v2 manifest

[101arrowz]

@hyusetiawan #7050 is a working PR to add MV3, you can check there for updates.