Chrome ha ucciso Manifest V2 in silenzio. Un giorno il Web Store ha smesso di accettare invii MV2. Se crei estensioni del browser come parte del tuo stack di prodotti indipendenti, la scadenza è già trascorsa.Manifesto V3non è più facoltativo. È l'unico gioco in città.

La questione non è se adottare MV3. La domanda è come ripensare la tua architettura in modo da smettere di combattere la piattaforma e iniziare a lavorarci. Questo cambiamento è più grande di quanto ammetta la maggior parte dei tutorial.

Perché MV3 sembra un runtime diverso

Pensa agli script in background MV2 come a un server che non dorme mai. Le tue variabili vivevano lì permanentemente. I tuoi timer hanno funzionato in modo affidabile. Lo Stato era sempre caldo e pronto.

MV3 lo sostituisce con aOperaio di servizio. I lavoratori dei servizi sono progettati per essere effimeri. Chrome può terminarli ogni volta che si verifica un sovraccarico della memoria, quindi riattivarli per l'evento successivo. Non vi è alcuna garanzia che il tuo lavoratore sia vivo tra due attivazioni di schede.

Questo non è un bug. È il disegno. Chrome ha fatto questo compromesso per ridurre la superficie di attacco per le estensioni dannose. Non importa se sei d’accordo con questo compromesso. La tua architettura deve tenerne conto.

L'implicazione più profonda: tutto ciò che hai memorizzato in una variabile all'interno dello script in background ora è mortale. Hai bisogno di un livello di persistenza esterno.chrome.storagediventa la tua unica fonte di verità, non un'API di convenienza.

Il problema dello spazio di archiviazione è più grande di quanto pensi

chrome.storage.local limita a 10 MB per impostazione predefinita. Per estensioni semplici che memorizzano le preferenze, questo è sufficiente. Per le estensioni che memorizzano nella cache le risposte API, tengono traccia del comportamento degli utenti o archiviano il contenuto dei documenti, 10 MB evaporano rapidamente.

La soluzione che la maggior parte degli sviluppatori trascura èDB indicizzato. Risiede nel browser, gestisce gigabyte di dati e supporta le transazioni. È accessibile da Service Worker, pagine popup e script di contenuto. Tuttavia, l'accesso di Service Worker a IndexedDB presentava bug di affidabilità nelle versioni precedenti di Chrome. Scegli come target Chrome 102 o versioni successive se segui questa strada.

Ecco una configurazione minima di IndexedDB che funziona in modo affidabile in MV3 Service Workers:

// storage.js, funziona con script SW, popup e contenuti
const DB_NAME = 'MyExtensionDB';
cost DB_VERSIONE = 1;

funzione di esportazione openDatabase() {
  return new Promise((risolvi, rifiuta) => {
    const req = indexedDB.open(DB_NAME, DB_VERSION);

    req.onupgradeneeded = (evento) => {
      const db = evento.obiettivo.risultato;
      if (!db.objectStoreNames.contains('cache')) {
        const store = db.createObjectStore('cache', { keyPath: 'key' });
        store.createIndex('timestamp', 'timestamp', { unique: false });
      }
    };

    req.onsuccess = (evento) => risolvere(event.target.result);
    req.onerror = (evento) => rifiuto(event.target.error);
  });
}

esporta la funzione asincrona saveRecord(chiave, dati) {
  const db = attendono openDatabase();
  return new Promise((risolvi, rifiuta) => {
    const tx = db.transaction('cache', 'readwrite');
    tx.objectStore('cache').put({ chiave, dati, timestamp: Date.now() });
    tx.oncomplete = risolvi;
    tx.onerror = rifiuta;
  });
}

Questo modello ti offre il ripristino in caso di arresto anomalo gratuitamente. Se Chrome uccide il tuo Service Worker a metà sessione, i dati sopravvivono. Quando il SW si riavvia, legge da IndexedDB e riprende in modo pulito.

I timer non sono più quelli di una volta

Gli sviluppatori singoli spesso creano estensioni che devono funzionare secondo una pianificazione. Pensa ai tracker dei costi, agli strumenti di promemoria o alle utilità di sincronizzazione. In MV2, hai lanciato unsetIntervalnello script in background e me ne sono dimenticato.

In MV3 questo approccio fallisce. Chrome potrebbe terminare il tuo Service Worker prima che venga attivato l'intervallo successivo. Ottieni delle lacune. Ricevi aggiornamenti persi. Ottieni utenti frustrati che inviano segnalazioni di bug.

La sostituzione èallarmi.cromati. Gli allarmi persistono durante i riavvii di Service Worker. Chrome attiva il tuo SW appositamente per gestire ogni evento di allarme. La limitazione è un periodo minimo di un minuto. Non è possibile attivare un allarme ogni cinque secondi.

Per gli aggiornamenti inferiori al minuto, il modello giusto è un approccio suddiviso. La tua pagina popup funziona da solasetIntervalmentre è aperta, perché le pagine popup hanno un ciclo di vita stabile mentre sono visibili. L'allarme gestisce la persistenza quando il popup è chiuso. Questo copre sia il caso di visualizzazione in tempo reale che il caso di persistenza in background senza hack.

Requisiti di sicurezza che ti prenderanno alla sprovvista

MV3 ha stretto ilPolitica sulla sicurezza dei contenutiin modo significativo. Due modelli che funzionavano in MV2 interromperanno la revisione dell'estensione o causeranno errori di runtime.

Nessuna esecuzione di script remoto

Se la tua estensione ha recuperato uno script da un CDN e lo ha eseguito dinamicamente, questo non c'è più. Tutto il JavaScript deve essere fornito in bundle con la tua estensione al momento dell'invio. Ciò influisce sulle estensioni che caricavano librerie di grafici, script di analisi o codice di utilità da URL esterni.

La soluzione è semplice: raggruppare tutto localmente utilizzando uno strumento di compilazione comeesbuildo Rollup. Ottieni un pacchetto più piccolo, più veloce e verificabile. Perderai la possibilità di inviare aggiornamenti JS senza un nuovo invio allo Store. Pianifica la cadenza di rilascio di conseguenza.

innerHTML è una responsabilità

MV3 non vietainnerHTMLa titolo definitivo. Tuttavia, il suo utilizzo con qualsiasi contenuto fornito dall'utente o recuperato dall'API crea un vettore XSS che i revisori contrassegneranno. Il CSP più rigido rende lo sfruttamento più difficile, ma la mossa giusta è smettere di usare interamente innerHTML per i contenuti dinamici.

Passa ai metodi di creazione DOM. Utilizzodocument.createElementEtestoContenutoper tutti i dati che non controlli completamente. Ciò semplifica anche il controllo della tua estensione, accelerando le revisioni del Web Store.

Quanto costa effettivamente MV3 agli sviluppatori solisti

Cerchiamo di essere onesti riguardo ai compromessi qui. La migrazione MV3 non è gratuita. Ecco cosa stai pagando:

Più codice asincrono:Ogni stato letto raggiunge lo spazio di archiviazione. Scrivi di più attendi le chiamate. Maggiore gestione degli errori. Più sovraccarico cognitivo.
Cicli di revisione più lunghi:Un CSP più severo significa un maggiore controllo da parte dei revisori. Budget tempo extra per la tua prima presentazione MV3.
Limiti di granularità degli allarmi:Il minimo di un minuto uccide completamente alcune idee di prodotto. I sistemi di controllo dei prezzi in background, i tracker in tempo reale e le funzionalità heartbeat necessitano tutti di una riprogettazione.
Disciplina del pacchetto:Nessuno script remoto significa che la tua pipeline di build è importante. Hai bisogno di un bundler adeguato se non lo hai già fatto.
Complessità del DB indicizzato:L'API basata su Promise è dettagliata. Avvolgilo presto o usa una libreria sottile comeun'astrazione di archiviazione ben documentataper i modelli di riferimento.

Inoltre, l'approccio asincrono forzato ovunque cambia il modo in cui esegui i test. I test unitari che si basavano su letture di stato sincrone devono essere riscritti. Inserisci questo fattore nella tua stima di migrazione.

Cosa ti dà MV3 in cambio

I vincoli hanno vantaggi reali. Il modello asincrono significa che l'estensione gestisce i riavvii del browser e si arresta in modo anomalo in modo corretto per impostazione predefinita. Gli utenti non perdono lo stato durante l'aggiornamento di Chrome. L'estensione si comporta in modo prevedibile tra le sessioni.

Il rafforzamento della sicurezza aiuta anche ad aumentare la fiducia. Gli utenti sono sempre più diffidenti nei confronti delle estensioni dopo anni di storie di malware. Un'estensione basata su MV3 con un pacchetto pulito e verificabile è più facile da spiegare agli utenti scettici. Se promuovi pubblicamente la tua estensione, quel segnale di fiducia è importante. UNstrumento gratuito di controllo dei social mediapuò aiutarti a valutare se il marketing della tua estensione sta generando i giusti segnali di credibilità su tutte le piattaforme.

Inoltre, la disciplina del raggruppamento forzato spesso produce estensioni più piccole e più veloci. Il caricamento lento viene sostituito dalla suddivisione deliberata del codice. Le prestazioni migliorano come effetto collaterale dei vincoli.

Passaggi pratici per la creazione della tua prossima estensione

Se stai iniziando una nuova estensione oggi o stai pianificando una migrazione, ecco una lista di controllo concreta:

Controlla ogni parte dello stato di cui ha bisogno la tua estensione. Decidi cosa va in chrome.storage.local, cosa va in IndexedDB e cosa può essere derivato su richiesta.
Sostituisci tutte le chiamate setInterval in background con chrome.alarms. Riprogetta qualsiasi funzionalità che necessitasse di aggiornamenti in background in meno di un minuto.
Raggruppa tutte le dipendenze localmente. Configura esbuild o Rollup prima di scrivere la prima riga del codice dell'estensione.
Sostituisci l'utilizzo di innerHTML con metodi DOM in ogni file che gestisce dati esterni.
Scrivi una funzione helper di openDB una volta e importala ovunque. Non riscrivere la configurazione di IndexedDB in ogni modulo.
Testare esplicitamente la cessazione del Service Worker. Utilizza Chrome DevTools per arrestare manualmente il tuo SW e verificare che l'estensione venga ripristinata correttamente.

ILrisorse di apprendimento web.devcoprire in modo approfondito il ciclo di vita dei Service Worker. Leggere la documentazione prima di progettare la logica in background ti farà risparmiare ore di debug dopo.

Strumenti adatti a un flusso di lavoro MV3

Gli sviluppatori solitari che creano estensioni spesso indossano ogni cappello. Scrivi il codice, progetti l'interfaccia utente e gestisci il marketing. Mantenere la toolchain snella è importante.

Per condividere la tua estensione durante il beta testing, ageneratore di codici QR gratuitoti consente di creare collegamenti scansionabili per la tua scheda del Chrome Web Store senza configurazioni aggiuntive. Utile per dimostrazioni dal vivo o cabine per conferenze.

Se la tua estensione acquisisce screenshot o elabora immagini, anRimozione sfondo AIti aiuta a creare rapidamente risorse promozionali pulite per l'elenco del Web Store.

Prima del lancio, esegui la pagina di destinazione della tua estensione tramite aselezionatore di siti Web gratuitoper individuare problemi di SEO e prestazioni che potrebbero danneggiare la scoperta organica.

Se la tua estensione elabora i file multimediali in qualche modo, è importante capire come funzionano i formati. UNconvertitore gratuito di video in MP3è un buon punto di riferimento per pensare al comportamento delle pipeline di elaborazione dei file basate su browser.

Anche l'accessibilità dell'interfaccia utente dell'estensione è importante. ILProgetto A11Ydispone di pratiche liste di controllo per rendere le pagine popup e gli script di contenuto utilizzabili da tutti. Questa è un'area che MV3 non affronta direttamente, ma i revisori del Web Store notano problemi di accessibilità.

Il risultato finale per gli sviluppatori di estensioni indipendenti

Manifesto V3è una piattaforma più difficile su cui costruire rispetto a MV2. I requisiti asincroni, i limiti di archiviazione e le restrizioni del timer creano reali attriti. Tuttavia, i vincoli spingono anche verso un codice più resiliente e più controllabile.

Gli sviluppatori che avranno maggiori difficoltà sono quelli che tentano di trasferire direttamente i pattern MV2. Gli sviluppatori che prospereranno sono quelli che accettano i nuovi vincoli come input di progettazione e ripensano la propria architettura dall’inizio.

Ne vale la pena? Per la maggior parte dei progetti di estensione indipendenti, sì. Il Web Store è ancora un canale di distribuzione praticabile. La base di utenti è enorme. Le opzioni di monetizzazione sono reali. Ora devi solo costruire in modo diverso.

Inizia con il tuo modello statale. Se lo fai bene, il resto della tua estensione MV3 andrà a posto. Se sbagli, passerai settimane a eseguire il debug dei casi limite di terminazione di Service Worker che sembrano bug casuali.

Questo post contiene link di affiliazione. Se effettui un acquisto tramite questi link, potremmo guadagnare una commissione senza costi aggiuntivi per te.