Use Manifest v3

[fregante]

• Closes Manifest v3 #55

This drops support for Firefox 🤷‍♂️

[fregante]

Blocked by:

• Web Extension Transformer: esmodule-helpers.js fails to load parcel-bundler/parcel#7952

[notlmn]

My bad, bad mouse clicks.

This drops support for Firefox 🤷‍♂️

Is there a tool out there that does manifest v2 generation from a manifest v3 configuration? That should still help with having two deployments to different stores.

[fregante]

Not that I know of. Currently it's impossible to use this template for Chrome so it's best to make the switch regardless of Firefox support (which is a small percentage of users)

[Stvad]

Firefox user here 😛 . It'd make me sad to see FF support dropped leaving me with no options for starting new extensions 🙁. I think having 2 manifests and 2 separate build commands that use those as entry points can be an option?

what @notlmn mentions (generating one version from another, or generating both versions from a common template) would be ideal, but just having 2 manifests should be an easy option to start with?

[fregante]

Indeed you can do that after using the template, but here it would mean duplicating every build command and the manifest itself, it's a mess. I assume Firefox is only a couple of months away from allowing MV3

[Stvad]

Aren't templates meant to make life with messes easier? 😅

[Stvad]

Also, I think not all commands, but just the build one?

[fregante]

Aren't templates meant to make life with messes easier? 😅

True, but you're assuming that what you're suggesting is easier, which it isn't. For a starter, parcel only works if the file is named exactly manifest.json. So if we have:

• source/manifest.json
• source/manifest-firefox.json

The second run gets:

❯ nr build
✨ Built in 550ms

distribution/manifest-firefox.js    734 B    106ms

So what's the alternative?

• Moving manifest for Firefox in another directory? Then its paths will all need to be updated too (assuming that works without pain)
• Duplicating the whole source folder? That'd be a terrible template.

At this point, if Firefox support is paramount, then I suggest going with a Webpack-based build like https://github.com/aeksco/react-typescript-web-extension-starter

[101arrowz]

We've fixed browser_specific_settings upstream, FF support should now still be possible from the same manifest. Unfortunately web_accessible_resources aren't completely fixed yet but basic functionality should still work.

[Stvad]

@fregante will experiment with different folders for manifest approach which seems like it can be ok and let you know how it goes!

[fregante]

@101arrowz thank you for the comment! From my understanding the latest version is broken for content scripts?

FF support should now still be possible from the same manifest.

FF completely fails to load MV3 extensions, this is not a Parcel issue unfortunately; browser_specific_settings was a relatively minor issue

[Stvad]

@fregante double-folder approach works btw, see manifest and package.json changes in transclude-me/extension@78b529e

[Stvad]

I'm hitting a weird bug with bundling though. It does not seem to be related to the double folder approach, but started happenign to me after 2.5 upgrade: parcel-bundler/parcel#8071

[aspiers]

@fregante double-folder approach works btw, see manifest and package.json changes in transclude-me/extension@78b529e

This commit appears to mix adding the double-folder approach together with a bunch of changes specific to your extension - right? Any chance you could summarise just the generic double-folder changes needed?

[Stvad]

That’s correct. Summary is:

• create 2 manifests
• Update paths in them
• add commands in package.json to deal with that
• beware the path change for the resources used via runtime.getURL (transclude-me/extension@78b529e#diff-ebd593fb607241eb184425ae1ae5b98a4c44f5ffc0355b2d0e485ad423caa29bR12)

[fregante]

Please continue in #78