Sådan skifter du til Manifest V3 til Chrome-udvidelser

Selvom jeg ikke er en almindelig Chrome-udvidelsesprogrammør, har jeg bestemt kodet nok udvidelser og har en bred nok webudviklingsportefølje til at kende mig rundt i opgaven. Men for nylig fik jeg en klient afvist en af ​​mine udvidelser, da jeg modtog feedback om, at min udvidelse var "forældet".

Mens jeg var i gang med at finde ud af, hvad der var galt, fejede jeg min forlegenhed ind under gulvtæppet og begyndte straks mit dybe dyk tilbage i verden af ​​Chrome Extensions. Desværre var informationen om Manifest V3 sparsom, og det var svært for mig hurtigt at forstå, hvad denne overgang gik ud på.

Det er overflødigt at sige, at med et ventende job måtte jeg møjsommeligt navigere rundt Googles Chrome-udviklerdokumentation og finde ud af tingene selv. Mens jeg fik arbejdet gjort, ønskede jeg ikke, at min viden og forskning på dette område skulle gå til spilde og besluttede at dele det, jeg ville ønske, jeg kunne have haft let adgang til i min læringsrejse.

Hvorfor overgangen til Manifest 3 er vigtig

Manifest V3 er en API, som Google vil bruge i sin Chrome-browser. Det er efterfølgeren til den nuværende API, Manifest V2, og styrer, hvordan Chrome-udvidelser interagerer med browseren. Manifest V3 introducerer væsentlige ændringer i reglerne for udvidelser, hvoraf nogle vil være den nye grundpille fra V2, vi var vant til.

Overgangen til Manifest V3 kan opsummeres som sådan:

1. Overgangen har været i gang siden 2018.
2. Manifest V3 begynder officielt at rulle ud i januar 2023.
3. I juni 2023 vil udvidelser, der kører Manifest V2, ikke længere være tilgængelige på Chrome Webshop.
4. Udvidelser, der ikke overholder de nye regler introduceret i Manifest V3, vil med tiden blive fjernet fra Chrome Webshop.

Et af hovedmålene med Manifest V3 er at gøre brugerne sikrere og forbedre den overordnede browseroplevelse. Tidligere var mange browserudvidelser afhængige af kode i skyen, hvilket betyder, at det kunne være svært vurdere, om en forlængelse var risikabel. Manifest V3 sigter mod at løse dette ved at kræve, at udvidelser indeholder al den kode, de vil køre, så Google kan scanne dem og opdage potentielle risici. Det tvinger også udvidelser til at anmode om tilladelse fra Google til de ændringer, de kan implementere på browseren.

Det er vigtigt at holde sig ajour med Googles overgang til Manifest V3, fordi den introducerer nye regler for udvidelser, der har til formål at forbedre brugersikkerheden og den overordnede browseroplevelse, og udvidelser, der ikke overholder disse regler, vil med tiden blive fjernet fra Chrome Web Butik.

Kort sagt kan alt dit hårde arbejde med at skabe udvidelser, der brugte Manifest V2, være for intet, hvis du ikke laver denne overgang i de kommende måneder.

De vigtigste forskelle mellem Manifest V2 og V3

Der er mange forskelle mellem de to, og selvom jeg stærkt anbefaler, at du læser videre Chromes guide til "Migrering til Manifest V3"., her er en kort og sød opsummering af nøglepunkter:

1. Servicemedarbejdere erstatte baggrundssider i Manifest V3.
2. Ændring af netværksanmodninger håndteres med den nye declarativeNetRequest API i Manifest V3.
3. I Manifest V3 kan udvidelser kun udføre JavaScript, der er inkluderet i deres pakke, og kan ikke bruge fjernhostet kode.
4. Manifest V3 introducerer promise understøttelse af mange metoder, selvom tilbagekald stadig understøttes som et alternativ.
5. Værtstilladelser i Manifest V3 er et separat element og skal angives i "host_permissions" felt.
6. Indholdssikkerhedspolitikken i Manifest V3 er et objekt med medlemmer, der repræsenterer alternative indholdssikkerhedspolitik (CSP) kontekster, snarere end en streng, som den var i Manifest V2.

I et simpelt Chrome-udvidelsesmanifest, der ændrer en websides baggrund, kan det se sådan ud:

// Manifest V2
{ "manifest_version": 2, "name": "Shane's Extension", "version": "1.0", "description": "A simple extension that changes the background of a webpage to Shane's face.", "background": { "scripts": ["background.js"], "persistent": true }, "browser_action": { "default_popup": "popup.html" }, "permissions": [ "activeTab", ], "optional_permissions": ["<all_urls>"]
}

// Manifest V3
{ "manifest_version": 3, "name": "Shane's Extension", "version": "1.0", "description": "A simple extension that changes the background of a webpage to Shane's face.", "background": { "service_worker": "background.js" }, "action": { "default_popup": "popup.html" }, "permissions": [ "activeTab", ], "host_permissions": [ "<all_urls>" ]
}

Hvis du synes, at nogle af tags ovenfor virker fremmede for dig, så fortsæt med at læse for at finde ud af præcis, hvad du har brug for at vide.

Sådan skiftes problemfrit til Manifest V3

Jeg har opsummeret overgangen til Manifest V3 i fire nøgleområder. Selvom der er mange klokker og fløjter i den nye Manifest V3, der skal implementeres fra den gamle Manifest V2, vil implementering af ændringer på disse fire områder selvfølgelig få din Chrome-udvidelse godt på rette vej til den eventuelle overgang.

De fire nøgleområder er:

1. Opdatering af dit Manifests grundlæggende struktur.
2. Rediger dine værtstilladelser.
3. Opdater indholdssikkerhedspolitikken.
4. Rediger håndteringen af ​​din netværksanmodning.

Med disse fire områder vil dit Manifests fundamentale være klar til overgangen til Manifest V3. Lad os se nærmere på hver af disse nøgleaspekter og se, hvordan vi kan arbejde hen imod at fremtidssikre din Chrome-udvidelse fra denne overgang.

Opdatering af dit Manifests grundlæggende struktur

Opdatering af dit manifests grundlæggende struktur er det første skridt i overgangen til Manifest V3. Den vigtigste ændring, du skal foretage, er at ændre værdien af "manifest_version" element til 3, som bestemmer, at du bruger Manifest V3-funktionssættet.

En af de største forskelle mellem Manifest V2 og V3 er udskiftningen af ​​baggrundssider med en enkelt udvidelsesservicemedarbejder i Manifest V3. Du skal registrere servicemedarbejderen under "background" felt ved hjælp af "service_worker" nøgle og angiv en enkelt JavaScript-fil. Selvom Manifest V3 ikke understøtter flere baggrundsscripts, kan du valgfrit erklære servicearbejderen som et ES-modul ved at angive "type": "module", som giver dig mulighed for at importere yderligere kode.

I Manifest V3 er "browser_action" , "page_action" ejendomme er samlet til en enkelt "action" ejendom. Du bliver nødt til at erstatte disse egenskaber med "action" i dit manifest. Tilsvarende "chrome.browserAction" , "chrome.pageAction" API'er er samlet i en enkelt "Action" API i Manifest V3, og du skal migrere til denne API.

// Manifest V2 "background": { "scripts": ["background.js"], "persistent": false
}, "browser_action": { "default_popup": "popup.html"
},

// Manifest V3 "background": { "service_worker": "background.js"
}, "action": { "default_popup": "popup.html"
}

Overordnet set er opdatering af dit manifests grundlæggende struktur et afgørende trin i processen med overgangen til Manifest V3, da det giver dig mulighed for at drage fordel af de nye funktioner og ændringer, der introduceres i denne version af API.

Rediger dine værtstilladelser

Det andet trin i overgangen til Manifest V3 er at ændre dine værtstilladelser. I Manifest V2 angiver du værtstilladelser i "permissions" felt i manifestfilen. I Manifest V3 er værtstilladelser et separat element, og du bør angive dem i "host_permissions" felt i manifestfilen.

Her er et eksempel på, hvordan du ændrer dine værtstilladelser:

// Manifest V2 "permissions": [ "activeTab", "storage", "http://www.css-tricks.com/", ":///*" ]

// Manifest V3 "permissions": [ "activeTab", "scripting", "storage"
], "host_permissions": [ "http://www.css-tricks.com/" ], "optional_host_permissions": [ ":///*" ]

Opdater indholdssikkerhedspolitikken

For at opdatere CSP'en for din Manifest V2-udvidelse, så den er kompatibel med Manifest V3, skal du foretage nogle ændringer i din manifestfil. I Manifest V2 blev CSP specificeret som en streng i "content_security_policy" manifestets felt.

I Manifest V3 er CSP'en nu et objekt med forskellige medlemmer, der repræsenterer alternative CSP-kontekster. I stedet for en enkelt "content_security_policy" felt, skal du nu angive separate felter for "content_security_policy.extension_pages" , "content_security_policy.sandbox", afhængigt af typen af ​​udvidelsessider, du bruger.

Du bør også fjerne eventuelle referencer til eksterne domæner i "script-src", "worker-src", "object-src"og "style-src" direktiver, hvis de er til stede. Det er vigtigt at lave disse opdateringer til din CSP for at sikre sikkerheden og stabiliteten af ​​din udvidelse i Manifest V3.

// Manifest V2 "content_security_policy": "script-src 'self' https://css-tricks.com; object-src 'self'"

// Manfiest V3 "content_security_policy.extension_pages": "script-src 'self' https://example.com; object-src 'self'", "content_security_policy.sandbox": "script-src 'self' https://css-tricks.com; object-src 'self'"

Rediger håndteringen af ​​din netværksanmodning

Det sidste trin i overgangen til Manifest V3 er at ændre din netværksanmodningshåndtering. I Manifest V2 ville du have brugt chrome.webRequest API til at ændre netværksanmodninger. Denne API er dog erstattet i Manifest V3 af declarativeNetRequest API.

For at bruge denne nye API skal du angive declarativeNetRequest tilladelse i dit manifest og opdatere din kode for at bruge den nye API. En vigtig forskel mellem de to API'er er, at declarativeNetRequest API kræver, at du angiver en liste over forudbestemte adresser, der skal blokeres, i stedet for at være i stand til at blokere hele kategorier af HTTP-anmodninger, som du kunne med chrome.webRequest API.

Det er vigtigt at foretage disse ændringer i din kode for at sikre, at din udvidelse fortsætter med at fungere korrekt under Manifest V3. Her er et eksempel på, hvordan du vil ændre dit manifest for at bruge declarativeNetRequest API i Manifest V3:

// Manifest V2 "permissions": [ "webRequest", "webRequestBlocking"
]

// Manifest V3 "permissions": [ "declarativeNetRequest"
]

Du skal også opdatere din udvidelseskode for at bruge declarativeNetRequest API i stedet for chrome.webRequest API.

Andre aspekter du skal tjekke

Det, jeg har dækket, er kun toppen af ​​isbjerget. Selvfølgelig, hvis jeg ville dække alt, kunne jeg være her i dagevis, og det ville ikke nytte noget at have Googles Chrome-udviklervejledninger. Selvom det, jeg dækkede, vil have dig fremtidssikret nok til at aktivere dine Chrome-udvidelser i denne overgang, er her nogle andre ting, du måske vil se på for at sikre, at dine udvidelser fungerer i toppen af ​​deres spil.

• Migrering af baggrundsscripts til service worker-udførelseskonteksten: Som tidligere nævnt erstatter Manifest V3 baggrundssider med en enkelt udvidelsesservicearbejder, så det kan være nødvendigt at opdatere baggrundsscripts for at tilpasse sig servicearbejderens eksekveringskontekst.
• At forene **chrome.browserAction** , **chrome.pageAction** API'er: Disse to tilsvarende API'er er samlet til en enkelt API i Manifest V3, så det kan være nødvendigt at migrere til Action API.
• Migrering af funktioner, der forventer en Manifest V2-baggrundskontekst: Adoptionen af ​​servicemedarbejdere i Manifest V3 er ikke kompatibel med metoder som f.eks chrome.runtime.getBackgroundPage(), chrome.extension.getBackgroundPage(), chrome.extension.getExtensionTabs()og chrome.extension.getViews(). Det kan være nødvendigt at migrere til et design, der sender beskeder mellem andre kontekster og baggrundsservicearbejderen.
• Flytning af CORS-anmodninger i indholdsscripts til baggrundsservicearbejderen: Det kan være nødvendigt at flytte CORS-anmodninger i indholdsscripts til baggrundsservicearbejderen for at overholde Manifest V3.
• Migrering væk fra eksekvering af ekstern kode eller vilkårlige strenge: Manifest V3 tillader ikke længere udførelse af ekstern logik vha chrome.scripting.executeScript({code: '...'}), eval()og new Function(). Det kan være nødvendigt at flytte al ekstern kode (JavaScript, WebAssembly, CSS) ind i udvidelsespakken, opdatere script- og stilreferencer for at indlæse ressourcer fra udvidelsespakken og bruge chrome.runtime.getURL() til at bygge ressource-URL'er under kørsel.
• Opdatering af visse scripting- og CSS-metoder i Tabs API: Som tidligere nævnt flytter flere metoder sig fra Tabs API til Scripting API i Manifest V3. Det kan være nødvendigt at opdatere eventuelle kald til disse metoder for at bruge den korrekte Manifest V3 API.

Og mange flere!

Du er velkommen til at bruge lidt tid på at blive opdateret på alle ændringerne. Når alt kommer til alt, er denne ændring uundgåelig, og hvis du ikke ønsker, at dine Manifest V2-udvidelser skal gå tabt på grund af at undgå denne overgang, så brug lidt tid på at bevæbne dig med den nødvendige viden.

På den anden side, hvis du er ny til at programmere Chrome-udvidelser og ønsker at komme i gang, er en god måde at gøre det på at dykke ned i Chromes webudviklerværktøjer. Det gjorde jeg gennem et kursus vedr Linkedin Learning, hvilket fik mig ret hurtigt op i fart. Når du har den grundlæggende viden, skal du vende tilbage til denne artikel og oversætte det, du ved, til Manifest V3!

Så hvordan vil jeg bruge funktionerne i den nye Manifest V3 fremover?

Nå, for mig, overgangen til Manifest V3 og fjernelse af chrome.webRequest API ser ud til at flytte udvidelser væk fra datacentrerede brugstilfælde (såsom annonceblokkere) til mere funktionelle og applikationsbaserede anvendelser. Jeg har holdt mig væk fra applikationsudvikling på det seneste, da det kan blive ret ressourceintensive til tider. Dette skift kan dog være det, der bringer mig tilbage!

Fremkomsten af ​​AI-værktøjer i nyere tid, mange med tilgængelige API'er, har udløst tonsvis af nye og friske SaaS-applikationer. Personligt synes jeg, at det kommer på et perfekt tidspunkt med skiftet til mere applikationsbaserede Chrome-udvidelser! Mens mange af de ældre udvidelser kan blive udslettet fra denne overgang, vil masser af nye bygget op omkring nye SaaS-ideer komme til at tage deres plads.

Derfor er dette en spændende opdatering til at hoppe på og forny gamle udvidelser eller bygge nye! Personligt ser jeg mange muligheder i at bruge API'er, der involverer AI, der bruges i udvidelser for at forbedre en brugers browsingoplevelse. Men det er egentlig kun toppen af ​​isbjerget. Hvis du virkelig ønsker at sætte dig ind i tingene med dine egne professionelle udvidelser eller nå ud til virksomheder for at bygge/opdatere udvidelser til dem, vil jeg anbefale opgradering af din Gmail-konto for de fordele, det giver ved at samarbejde, udvikle og udgive udvidelser til Chrome Webshop.

Husk dog, at enhver udviklers krav er forskellige, så lær hvad du har brug for for at holde dine nuværende udvidelser oven vande, eller dine nye!

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
• Kilde: https://css-tricks.com/how-to-transition-to-manifest-v3-for-chrome-extensions/