Open emorling opened 3 years ago
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.
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:
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
__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"
}
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",
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",
},
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 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:
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!
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.
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: optimize-css-assets-webpack-plugin@6.0.1
npm ERR! Found: webpack@5.90.0
npm ERR! node_modules/webpack
npm ERR! dev webpack@"^5.90.0" from the root project
npm ERR! webpack@"^5" from @types/webpack@5.28.5
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 webpack-ext-reloader@1.1.12
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 optimize-css-assets-webpack-plugin@6.0.1
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: webpack@4.47.0
npm ERR! node_modules/webpack
npm ERR! peer webpack@"^4.0.0" from optimize-css-assets-webpack-plugin@6.0.1
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 ? 🤔
@abhijithvijayan Google has announced that devs need to migrate to V3 by June.
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.