web-extension-starter

web-extension-starter copied to clipboard

Any plans on upgrading this to work with manifest V3? Or a list of manual changes that need to be done? It doesn't seem to work out of the box for V3.

any update?

I think this is the best documentation on what an upgrade från V2 to V3 implies:

https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/

@emorling i dont think manifest v3 is being pushed to firefox anytime soon.

https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/&sa=U&ved=2ahUKEwjzjvWNw8jxAhWyzDgGHdBMDxsQFjACegQIBxAB&usg=AOvVaw0PczMyb3bHfV4NeFcKdH8F

I will not be implementing this until a beta release from these browser vendors are out and they provide viable migration guides for both.

Background scripts are now being replaced with workers, so I dont want to make partial support to chome and no support to firefox.

Probably its a good call to wait. And I would like to see some open source extensions already working on this hell of a migration.

Google is so arrogant with their release of manifest v3. This might be a good time to see what is to be done for the benefit of Firefox too. Ideas are welcome.

ref:

• https://notifications.google.com/g/p/AD-FnEwrN93eXn0b5AP95dRBU0YwudmB9ByX1YS7DC_Ggy8__nw8iKBYTbZaU-HMtjrrC-Rw2MQujhrKNQ22d-UeyNE10L-2UA8Wr2dRGPoR3OxHr6b2IFwkGHQqFRuDpKplIqcD9ozPQQ09YoRM_G9e22s
• https://notifications.google.com/g/p/AD-FnExwAlrttqBskkkpJx_UHy4EaBCASJ424guQp5S-piDtDeqB9gmZo_uijXEaQ5n6q4boIyPuGgwqvxSPV4FG5j8SHAAq7Q_E9NXiNPtHUpy7uNa_Jdw
• https://notifications.google.com/g/p/AD-FnEy8FV93DiKUfek3RICrW7-nmy3jrmWYE7N_ddozRw1O4ffKy2fih1IMDtkVbS-QQ1jxzzMDhZok_D2x-tbuEwJHMbItsDi__die51fwHak6_3YIxENSNSVBLMo6xYXDHQ

Update:

• The underlying polyfill by Mozilla has an issue open with respect to support for Chrome's v3 APIs see: https://github.com/mozilla/webextension-polyfill/issues/329#issuecomment-884938069

• The initial steps to be done for the manifest.json mentioned in migration guide can be accomplished by vendor prefixed keys (docs] eg:

       "__chrome|opera|edge__manifest_version": 3,
       "__firefox__manifest_version": 2
  

  • Note: if you are going with keeping Opera/Edge/Other Chromium based browsers in sync with that of Chrome, the keys would have to be adjusted like __chrome|opera|edge__ & __firefox__. This depends on the browser backward compatibility you are intending to accomplish.

• Dropping support for older chrome/edge/opera/brave versions by modifying targets field in .babelrc file

    "targets": {
             "chrome": "88",
             "firefox": "52",
             "opera": "74",
             "edge": "88"
       }
  

• and also manifest.json should be updated

       "__firefox__browser_specific_settings": {
  	        "gecko": {
  	          "id": "{some_id}",
  	          "strict_min_version": "52.0"
  	        }
       },
       "__chrome__minimum_chrome_version": "88",
       "__opera__minimum_opera_version": "74",
  

  • Note: chrome can be of version 88 and opera can be of 74 (which has Chromium 88), for edge i think 88 is needed as from what i saw on wikipedia, edge keeps version in sync with that of chromium's.

• Deprecated APIs will be rendered useless for users of Chromium-based browsers(before v87) after January 2023

• using service workers for chrome can be adopted by providing a separate background script(using manifest vendor prefixed key)

  background": {
       "__firefox__scripts": [
         "js/background.bundle.js"
       ],
       "__chrome|opera|edge__service_worker": "js/bgServiceWorker.js",
  },
  

  • Note: new file entry (bgServiceWorker: path.join(sourcePath, 'Background', 'service-worker.ts'),) has to be added to https://github.com/abhijithvijayan/web-extension-starter/blob/a3459c3064f8ce30ea8f5e0f41c49c2d223ceaa2/webpack.config.js#L60 and also source/Background/service-worker.ts has to have all the logic for the chromium based browsers
  • If you have a better approach like either by merging the logic between APIs for chromium 87 and that of Firefox, feel free to use a single bundle js for that.
  • https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/#manifest

I think this would help in the migration, If I get some time, I will test this myself. As of now all the extensions that i have is already on chrome store which means I have an year more for the migration. But for the new extensions created after January 17, migration is very much needed for chrome team to accept the extension into their store.

Hope this helps!

Like always, contributions & support are welcome from anyone.

@abhijithvijayan , I test it in one of my project and it's working fine. I think minimum chrome version will be 88.

The extension hot reloading library also lacks support for this.

https://github.com/SimplifyJobs/webpack-ext-reloader/issues/28

The wext-manifest-loader library (v2.4.1) now supports env variables alongside vendor prefixes https://github.com/abhijithvijayan/wext-manifest-loader#2-how-can-i-conditionally-set-keys-based-on-environment

For development/production env for chrome we now can use manifest v3 fields For development/production env for firefox we now can use manifest v2 fields

  "__chrome|opera|edge__manifest_version": 3,
  "__firefox__manifest_version": 2,

  "__chrome|opera|edge|dev__content_security_policy": {
    "extension_pages": "script-src 'self' http://localhost:8097; object-src 'self'"
  },

  "__chrome|opera|edge|prod__content_security_policy": {
    "extension_pages": "script-src 'self'; object-src 'self'"
  },

  "__firefox|dev__content_security_policy": "script-src 'self' http://localhost:8097; object-src 'self'",
  "__firefox|prod__content_security_policy": "script-src 'self'; object-src 'self'",

For chrome in production, the output manifest will have

  "manifest_version": 3,
  "content_security_policy": {
    "extension_pages": "script-src 'self'; object-src 'self'"
  }

For firefox in production, the output manifest will have

  "manifest_version": 2,
  "content_security_policy": "script-src 'self'; object-src 'self'"

I have published an extension last week to firestore and chrome with manifest 2 and 3 combined(with content script only

~https://github.com/abhijithvijayan/Resume-Downloader/blob/main/source/manifest.json~

Edit:

https://pastebin.com/raw/rurMH5Zh

I have published an extension last week to firestore and chrome with manifest 2 and 3 combined(with content script only

https://github.com/abhijithvijayan/Resume-Downloader/blob/main/source/manifest.json

Link giving a 404, possible to update it? Hoping to see an example to help migrate!

updated link: https://pastebin.com/raw/rurMH5Zh

starting end of January 2023 Firefox will support MV3 https://blog.mozilla.org/addons/2022/11/17/manifest-v3-signing-available-november-21-on-firefox-nightly/

also staring January, Chrome store will no longer show the featured badge for MV2 extensions: https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/

seems like Google has postponed their timeline https://9to5google.com/2022/12/12/manifest-v2-chrome-extension/

I've just tried to upload an extension with a v2 manifest to the Chrome store but get this error: "You can no longer publish new Manifest V2 extensions. Try converting your extension to Manifest V3."

Looks like (almost) end of this year v2 will be blocked/purged https://developer.chrome.com/blog/more-mv2-transition/

In January 2024, following the expiration of the Manifest V2 enterprise policy, the Chrome Web Store will remove all remaining Manifest V2 items from the store.

https://github.com/kyle-n/WebExtensionTemplate appears to have v3 support

The timeline has since been updated but yeah in 2024 the migration looks to be happening https://developer.chrome.com/blog/resuming-the-transition-to-mv3/

The extension hot reloading library also lacks support for this.

SimplifyJobs/webpack-ext-reloader#28

FWIW, webpack-ext-reloader supports MV3 as of v1.1.10

migrated dependency libraries to support both webpack 4 and webpack 5

wext-manifest-webpack-plugin@^1.4.0
wext-manifest-loader@^2.4.1

i will get the template to support webpack 5 too. hopefully all the depedencies support webpack 5 now

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/webpack
npm ERR!   dev webpack@"^5.90.0" from the root project
npm ERR!   webpack@"^5" from @types/[email protected]
npm ERR!   node_modules/@types/webpack
npm ERR!     dev @types/webpack@"^5.28.5" from the root project
npm ERR!     @types/webpack@"^5.28.5" from [email protected]
npm ERR!     node_modules/webpack-ext-reloader
npm ERR!       dev webpack-ext-reloader@"^1.1.12" from the root project
npm ERR!   16 more (@webpack-cli/configtest, @webpack-cli/info, ...)
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer webpack@"^4.0.0" from [email protected]
npm ERR! node_modules/optimize-css-assets-webpack-plugin
npm ERR!   dev optimize-css-assets-webpack-plugin@"^6.0.1" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: [email protected]
npm ERR! node_modules/webpack
npm ERR!   peer webpack@"^4.0.0" from [email protected]
npm ERR!   node_modules/optimize-css-assets-webpack-plugin
npm ERR!     dev optimize-css-assets-webpack-plugin@"^6.0.1" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! 
npm ERR! For a full report see:
npm ERR! /Users/dk/.npm/_logs/2024-02-02T19_20_04_233Z-eresolve-report.txt

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/dk/.npm/_logs/2024-02-02T19_20_04_233Z-debug-0.log

any update on this ? 🤔