[Feature] Specify `manifest.json` path

[ffoodd]

Reviving #1034.

Currently working on a manifest V2 → V3 migration, separate manifest files are needed for Firefox and Chromium based browsers:

• background entry needs a service_worker string for Chromium, but a scripts strings array for Firefox ;
• Firefox needs browser_specific_settings mostly to set gecko.id.

I currently have two manifests, and use npm scripts to temporary rename e.g. the Firefox manifest before packaging my extension. I can't see a workaround since browsers reject a manifest containing what they consider as invalid entries in the manifest file—but that's the only file that needs to be different. Content and background scripts, assets, images… are the same for Firefox and Chromium, so I definitely don't want to maintain a folder for both, with duplicate files all over.

That means I'm unable to use web-ext to either build or run my extension since I cannot specify the manifest file to use. I could keep going with temporarily renaming files before using web-ext (using pre npm script hooks), which I’d like to drop, obviously.

Could it make sense to handle this argument for web-ext CLI with the the upcoming MV3 era? And if not, I think it could be explained somewhere with some hints and how-to handle this, couldn't it?

[Rob--W]

There was recent discussion of this scenario at issue #2281.

From a different angle, not the tooling perspective, but the browser engineering one:

There is consensus across browser vendors that unsupported properties should be ignored (potentially with a warning to developers), but should not prevent the extension from being loaded. The browser_specific_settings key is explicitly designed to support the use case of having browser-specific settings in that field.

Presently, Chrome refuses to load the extension and reports "The "background.scripts" key cannot be used with manifest_version 3. Use the "background.service_worker" key instead." In the future, Chrome will not refuse to load the extension any more: w3c/webextensions#282 (comment) & w3c/webextensions#282 (comment) (https://bugs.chromium.org/p/chromium/issues/detail?id=1418934). Until that bug has been fixed and shipped for a while, extension authors still need to customize the manifest per browser. But longer-term, the cross-browser developer experience will hopefully be better than it is today.

[ffoodd]

I understand.

To go further, Firefox currently also refuses scripts.service_worker even though when scripts is missing, it mentions service_worker as a potential fix. I may have missed something .

As web-ext is meant to ease web extension development, I presumed the developer angle would be the main (if not the only) to be considered.

I know the whole Manifest v3 move is painful for everyone (except Google / Chrome, yet struggling with their own deadlines and nonsenses).

[Rob--W]

Ideally, extension authors should be able to use one source dir for both Chrome and Firefox.

When that is not possible (e.g. due to Chrome refusing to load when background.service_worker and background.scripts are both present), then my preferred solution is for that validation to be loosened, which is the path being pursued at w3c/webextensions#282 (comment) (crbug: https://bugs.chromium.org/p/chromium/issues/detail?id=1418934).

When that is not possible, i.e. when an two manifest.json files are needed, then there would be a need to have an intermediate build step. Sometimes it's just one manifest.json file, but often the degree of incompatibilities means that there are also differences in source files. Therefore the generic solution is to introduce a build step and run web-ext from there. This was mentioned at #2281 . There are are many ways to build before running (e.g. through npm scripts in package.json, through Makefile (example in one of my extensions), etc).

web-ext run is currently equivalent to selecting the current directory via the "Load unpacked extension" button (Chrome: chrome://extensions) or "Load Temporary Add-on" (Firefox: about:debugging -> This Nightly). If we were to introduce a flag to customize the manifest.json file, then this guarantee (of the source matching the observed result) is no longer true. We therefore consider these kind of source transformations out of scope.

I'll mark this as wontfix, but keep it opened for visibility, since the incompatible manifest.json is a frequently encountered issue as developers try to develop MV3 extensions for Firefox and Chrome.

[ffoodd]

Thanks for the detailed answer, makes sense!