Kas pasikeitė ir kodėl verta susipažinti su Manifest V3
Jei kada nors kūrėte Chrome plėtinius arba tik planuojate pradėti, turbūt jau girdėjote apie Manifest V3. Tai naujausia Chrome plėtinių platformos versija, kuri iš esmės pakeičia tai, kaip kuriame ir valdome plėtinius. Google pradėjo šį perėjimą dar 2020 metais, o nuo 2024-ųjų pradžios Manifest V2 plėtiniai palaipsniui išjungiami Chrome Web Store.
Pirmoji reakcija daugelio kūrėjų buvo… na, švelniai tariant, ne itin entuziastinga. Kodėl? Nes kai kurie pakeitimai reikalauja iš esmės permąstyti, kaip veikia jūsų plėtinys. Tačiau pasigilinus tampa aišku, kad daugelis šių pokyčių iš tikrųjų yra prasminga evoliucija. Manifest V3 sukurtas atsižvelgiant į saugumą, privatumą ir našumą – tris dalykus, kurie šiuolaikinėje interneto erdvėje yra kritiškai svarbūs.
Pagrindinis skirtumas? Manifest V3 riboja tai, kaip plėtiniai gali vykdyti kodą ir prieiti prie tinklalapių duomenų. Tai gali skambėti kaip apribojimas (ir iš dalies taip ir yra), bet kartu tai reiškia, kad vartotojai gali būti ramūs dėl to, kad įdiegtas plėtinys nedarys nieko keisto fone.
Manifest failo struktūra ir pagrindiniai skirtumai
Pradėkime nuo paties manifest.json failo – tai jūsų plėtinio širdis. Manifest V3 versijoje šis failas atrodo šiek tiek kitaip nei įpratę. Štai paprastas pavyzdys:
„`json
{
„manifest_version”: 3,
„name”: „Mano Super Plėtinys”,
„version”: „1.0.0”,
„description”: „Plėtinys, kuris daro nuostabius dalykus”,
„permissions”: [
„storage”,
„activeTab”
],
„host_permissions”: [
„https://*.example.com/*”
],
„action”: {
„default_popup”: „popup.html”,
„default_icon”: {
„16”: „images/icon16.png”,
„48”: „images/icon48.png”,
„128”: „images/icon128.png”
}
},
„background”: {
„service_worker”: „background.js”
}
}
„`
Pirmasis dalykas, kurį pastebėsite – `manifest_version: 3`. Tai būtina nurodyti, kad Chrome žinotų, jog naudojate naują versiją. Kitas svarbus pokytis – `permissions` ir `host_permissions` dabar yra atskirti. Anksčiau viskas buvo kraunama į vieną `permissions` masyvą, dabar prieiga prie konkretaus domeno reikalauja atskiro deklaravimo.
Beje, jei anksčiau naudojote `browser_action` ar `page_action`, dabar tai sujungta į vieną `action` lauką. Tai iš tikrųjų supaprastina dalykus, nes nebereikia galvoti, kurį variantą pasirinkti.
Service Workers vietoj Background Pages
Čia prasideda tikrasis iššūkis. Manifest V2 leido turėti background page – HTML puslapį, kuris veikė fone ir galėjo vykdyti kodą nepertraukiamai. Manifest V3 tai pakeičia service workers. Ir tai nėra tik pavadinimo pakeitimas.
Service workers yra event-driven. Tai reiškia, kad jie pažadinami tik tada, kai kažkas nutinka, atlieka savo darbą ir vėl „užmiega”. Negalite tiesiog turėti kintamojo, kuris išliktų atmintyje visą laiką. Štai pavyzdys, kaip tai veikia:
„`javascript
// background.js
chrome.runtime.onInstalled.addListener(() => {
console.log(‘Plėtinys įdiegtas!’);
chrome.storage.local.set({ counter: 0 });
});
chrome.action.onClicked.addListener(async (tab) => {
const data = await chrome.storage.local.get([‘counter’]);
const newCounter = (data.counter || 0) + 1;
await chrome.storage.local.set({ counter: newCounter });
console.log(`Paspaustas ${newCounter} kartą`);
});
„`
Matote? Vietoj to, kad laikytume `counter` kintamąjį atmintyje, naudojame `chrome.storage`. Tai gali atrodyti kaip papildomas darbas, bet iš tikrųjų tai skatina geresnę praktiką ir sumažina atminties naudojimą.
Vienas dalykas, kuris gali sukelti problemų – service workers negali naudoti `XMLHttpRequest`. Turite naudoti `fetch()` API. Jei jūsų senas kodas rėmėsi XHR, reikės jį perrašyti. Bet atvirai kalbant, `fetch()` yra šiuolaikiškas ir daug patogesnės API, tad tai greičiau atnaujinimas nei žingsnis atgal.
Content Scripts ir jų apribojimai
Content scripts – tai JavaScript failai, kurie įterpiami į tinklalapius ir gali sąveikauti su DOM. Manifest V3 čia iš esmės nieko drastiško nepakeitė, bet yra keletas niuansų, kuriuos verta žinoti.
Pirmiausia, jei norite dinamiškai įterpti content script, dabar naudojate `chrome.scripting.executeScript()` vietoj senojo `chrome.tabs.executeScript()`. Štai kaip tai atrodo:
„`javascript
chrome.action.onClicked.addListener(async (tab) => {
await chrome.scripting.executeScript({
target: { tabId: tab.id },
func: () => {
document.body.style.backgroundColor = ‘lightblue’;
}
});
});
„`
Patogus dalykas – galite perduoti funkciją tiesiogiai, o ne tik failo pavadinimą. Tai daro kodą skaitomesnį ir lengviau testuojamą.
Tačiau yra vienas svarbus apribojimas – content scripts negali naudoti `eval()` ar panašių funkcijų, kurios vykdo stringus kaip kodą. Tai saugumo priemonė, bet jei jūsų plėtinys rėmėsi tokia funkcionalumu, teks ieškoti alternatyvų. Dažniausiai tai reiškia, kad reikia iš anksto apibrėžti visas galimas operacijas ir naudoti switch/case arba objektų žodynus.
Declarative Net Request – nauja taisyklių era
Čia yra didžiausias ir labiausiai kontraversiškas Manifest V3 pokytis. Senasis `webRequest` API, kuris leido plėtiniams stebėti ir modifikuoti tinklo užklausas realiu laiku, dabar pakeistas į `declarativeNetRequest`.
Skirtumas fundamentalus: vietoj to, kad jūsų JavaScript kodas galėtų perimti kiekvieną užklausą ir nuspręsti, ką su ja daryti, dabar turite iš anksto apibrėžti taisykles JSON formatu. Chrome pats jas apdoroja natyviu lygmeniu, o jūsų kodas net neįsijungia.
Štai paprastas pavyzdys, kaip blokuoti reklamas:
„`json
{
„id”: 1,
„priority”: 1,
„action”: {
„type”: „block”
},
„condition”: {
„urlFilter”: „||ads.example.com^”,
„resourceTypes”: [„script”, „image”]
}
}
„`
Šias taisykles deklaruojate manifest.json faile arba įkeliate dinamiškai per API. Taip, yra limitas – maksimaliai 30,000 statinių taisyklių ir 5,000 dinaminių. Tai gali atrodyti daug, bet kai kuriems ad blockers tai per maža. Todėl ir kilo tiek triukšmo.
Bet štai kas įdomu – šis metodas iš tikrųjų yra greitesnis ir saugesnis. Kadangi taisyklės vykdomos natyviu lygmeniu, nėra JavaScript overhead. Plėtinys negali „pamatyti” jūsų naršymo duomenų, nes viskas vyksta Chrome viduje. Tai gerai privatumui.
Jei kuriate naują plėtinį, patarčiau nuo pradžių mąstyti declarative požiūriu. Užuot galvojus „kaip mano kodas apdoros šią užklausą”, galvokite „kokią taisyklę galiu sukurti, kad Chrome tai padarytų už mane”.
Permissions ir Host Permissions strategija
Manifest V3 daug griežtesnis dėl leidimų. Tai gera žinia vartotojams, bet kūrėjams reikia būti atsargesniems.
Pirmiausia, vengkite prašyti `
„`json
„host_permissions”: [
„https://github.com/*”,
„https://gitlab.com/*”
]
„`
Kitas svarbus dalykas – `activeTab` leidimas. Tai vienas geriausių Manifest V3 papildymų. Jis leidžia jūsų plėtiniui prieiti prie dabartinio aktyvaus tab’o, bet tik tada, kai vartotojas aktyviai sąveikauja su jūsų plėtiniu (pavyzdžiui, spaudžia jo ikoną). Tai idealus balansas tarp funkcionalumo ir privatumo:
„`json
„permissions”: [
„activeTab”,
„storage”
]
„`
Su `activeTab` galite skaityti ir modifikuoti puslapį be jokių `host_permissions`. Vartotojui tai reiškia, kad plėtinys neturi nuolatinės prieigos prie visų jo lankytų puslapių.
Dar vienas patarimas – naudokite optional permissions, kai įmanoma. Tai leidžia prašyti papildomų leidimų tik tada, kai jie tikrai reikalingi:
„`javascript
chrome.permissions.request({
permissions: [‘downloads’],
origins: [‘https://api.example.com/*’]
}, (granted) => {
if (granted) {
// Dabar galime naudoti downloads API
}
});
„`
Debugging ir testavimas naujoje aplinkoje
Manifest V3 plėtinių debuginimas turi savo ypatumų. Service workers neturi nuolatinio DevTools lango – jis atsiranda tik tada, kai service worker aktyvus.
Kad pamatytumėte savo service worker logus, eikite į `chrome://extensions/`, įjunkite Developer mode ir spustelėkite „service worker” nuorodą po savo plėtiniu. Tai atvers DevTools langą. Bet atminkite – kai tik uždarote šį langą, service worker gali vėl „užmigti”.
Vienas trikis debuginimui – galite dirbtinai išlaikyti service worker aktyvų DevTools lange naudodami debugger statement:
„`javascript
chrome.runtime.onInstalled.addListener(() => {
// debugger; // Iškomentavus, service worker liks aktyvus
console.log(‘Extension installed’);
});
„`
Content scripts debuginami kaip įprasta – tiesiog atidarykite DevTools tame puslapyje, kur jie veikia. Jūsų content script kodas bus matomas Sources skirtuke.
Dar vienas naudingas įrankis – `chrome.storage` galite peržiūrėti tiesiogiai DevTools. Eikite į Application → Storage → Extension Storage. Čia matysite visus jūsų išsaugotus duomenis realiu laiku.
Testavimui rekomenduoju naudoti Jest su chrome-extension-testing-library arba Puppeteer su Chrome headless režimu. Taip galite automatizuoti testus ir įsitikinti, kad viskas veikia teisingai prieš publikuojant:
„`javascript
// Paprastas unit testas
test(‘counter increases correctly’, async () => {
await chrome.storage.local.set({ counter: 5 });
const result = await chrome.storage.local.get([‘counter’]);
expect(result.counter).toBe(5);
});
„`
Migravimas iš Manifest V2: praktiniai žingsniai
Jei turite esamą Manifest V2 plėtinį, migracija gali atrodyti bauginanti, bet ji tikrai įmanoma. Štai kaip aš rekomenduoju tai daryti:
**1. Pradėkite nuo manifest.json failo**
Pakeiskite `manifest_version` į 3 ir atnaujinkite sintaksę. Perskirstykite permissions į `permissions` ir `host_permissions`. Pakeiskite `browser_action`/`page_action` į `action`.
**2. Konvertuokite background page į service worker**
Tai dažniausiai sudėtingiausia dalis. Pirmiausia, perkelkite visą kodą iš background.html į background.js. Tada:
– Pašalinkite visus globalius kintamuosius – naudokite `chrome.storage` vietoj jų
– Pakeiskite `XMLHttpRequest` į `fetch()`
– Įsitikinkite, kad visi event listeners yra registruojami top-level (ne funkcijų viduje)
**3. Atnaujinkite content scripts injection**
Jei naudojote `chrome.tabs.executeScript()`, pakeiskite į `chrome.scripting.executeScript()`. Nepamirškite pridėti `scripting` permission.
**4. Perrašykite webRequest logiką**
Jei naudojote `webRequest` API, tai bus didžiausias darbas. Išanalizuokite, ką tiksliai darote su užklausomis, ir pamėginkite išreikšti tai declarative taisyklėmis. Jei tai neįmanoma, galbūt reikės persvarstyti plėtinio architektūrą.
**5. Išbandykite viską**
Įkelkite plėtinį kaip unpacked extension ir kruopščiai ištestuokite visas funkcijas. Ypač atkreipkite dėmesį į tai, kas vyksta po service worker „užmigimo” ir „pažadinimo”.
Vienas patarimas iš patirties – nesinervinkite, jei kas nors neveikia iš karto. Manifest V3 tikrai reikalauja kitokio mąstymo būdo, bet kai įsigilinsite, daugelis dalykų tampa logiškesni.
Ateities perspektyvos ir ko tikėtis toliau
Manifest V3 nėra galutinis tikslas – tai platforma, kuri toliau vystosi. Google jau paskelbė, kad klausosi bendruomenės atsiliepimų ir planuoja tobulinimus. Pavyzdžiui, `declarativeNetRequest` taisyklių limitas jau buvo padidintas po kūrėjų prašymų.
Kas tikrai aišku – Manifest V2 laikas baigiasi. Nuo 2024 metų birželio nauji Manifest V2 plėtiniai nebepriimami į Chrome Web Store, o esami palaipsniui išjungiami. Tai reiškia, kad jei rimtai galvojate apie Chrome plėtinių kūrimą, Manifest V3 yra vienintelis kelias į priekį.
Bet tai nebūtinai blogai. Taip, yra apribojimų, bet kartu yra ir naujų galimybių. Service workers yra greitesni ir efektyvesni. Declarative taisyklės suteikia geresnį našumą. Griežtesni leidimai reiškia, kad vartotojai labiau pasitiki plėtiniais.
Jei tik pradedate kurti plėtinius, jums pasisekė – galite mokytis iš karto teisingai, be jokios migracijos skausmo. O jei migruojate esamą plėtinį, žinokite, kad daugelis kūrėjų jau tai padarė sėkmingai. Yra daug resursų, pavyzdžių ir bendruomenės pagalbos.
Manifest V3 gali būti iššūkis, bet tai iššūkis, kuris veda link geresnių, saugesnių ir efektyvesnių plėtinių. Ir galiausiai – argi ne tai yra tikslas?
