Jak budować rozszerzenia Chrome z React, Vite i CRXJS w 2026

1. Dlaczego rozszerzenia przeglądarki są niedoceniane

Rozszerzenia przeglądarki zajmują unikalne miejsce: mają dostęp do stron, na których Twoi użytkownicy już pracują, nie wymagają osobnej instalacji aplikacji i mogą automatyzować workflow, który normalnie wymaga przełączania się między wieloma zakładkami.

Potencjał rynkowy jest znaczący. Według StatCounter (2026), Chrome ma około 65% globalnego udziału w rynku przeglądarek. Chrome Web Store hostuje ponad 125 000 rozszerzeń, a przeglądarki oparte na Chromium (Edge, Brave, Opera, Arc) jeszcze bardziej rozszerzają potencjalny zasięg. Rozszerzenia zbudowane dla Chrome działają na wszystkich z nich z minimalnymi modyfikacjami.

Dla firm e-commerce to szczególnie potężne narzędzie. Rozszerzenie może wstrzyknąć porównanie cen bezpośrednio na stronę konkurencji, zautomatyzować operacje masowe w panelach marketplace'ów czy dodać fakturowanie jednym kliknięciem do panelu zarządzania zamówieniami.

ROI jest często natychmiastowy: zespoły raportują oszczędność 2-4 godzin dziennie na powtarzalnych zadaniach w przeglądarce po wdrożeniu dedykowanego rozszerzenia. To czas, który wraca bezpośrednio do rozwoju biznesu. Więcej o budżetach i harmonogramach znajdziesz w naszym przewodniku o prawdziwych kosztach budowy rozszerzenia.

2. Stack: Vite + CRXJS + React + TypeScript

Nasz stack produkcyjny został dopracowany przez ponad 100 wersji rozszerzeń. Oto czego używamy i dlaczego. Szczegółowe porównanie frameworków znajdziesz w naszym artykule CRXJS vs Plasmo vs WXT.

// vite.config.ts
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import crx from '@crxjs/vite-plugin';
import manifest from './manifest.json';

export default defineConfig({
  plugins: [
    react(),
    crx({ manifest }),
  ],
});

Ten stack daje nam hot module replacement w content scriptach (tak, widzisz zmiany wstrzykiwane na żywą stronę bez odświeżania), typowo-bezpieczną komunikację między kontekstami rozszerzenia i doświadczenie developerskie jak przy budowaniu zwykłej aplikacji React.

Każde rozszerzenie, które budujemy, jest pokryte testami end-to-end, integracyjnymi i jednostkowymi. Testy E2E weryfikują pełną ścieżkę użytkownika w przeglądarce, testy integracyjne walidują poprawną komunikację między content scripts, background workers i popupami, a testy jednostkowe zabezpieczają poszczególne narzędzia i logikę biznesową. To warstwowe podejście łapie regresje zanim trafią na produkcję.

3. Manifest V3: co się naprawdę zmieniło

Manifest V3 (MV3) zastąpił V2 jako wymagany format rozszerzeń Chrome. Google wycofuje MV2, więc wszystkie nowe rozszerzenia muszą używać V3. Oto zmiany, które mają znaczenie w praktyce:

Praktyczny wpływ: jeśli budujesz od nowa, MV3 to po prostu sposób, w jaki rozszerzenia teraz działają - a my jesteśmy MV3 native. Każde rozszerzenie, które budujemy, startuje na Manifest V3 od pierwszego dnia, nie jako migracja z V2. Jeśli migrujesz starsze rozszerzenie z MV2, przejście na service workers jest największym wyzwaniem. Przeprowadziliśmy tę migrację dla wielu klientów i możemy pomóc.

{
  "manifest_version": 3,
  "name": "My Extension",
  "version": "1.0.0",
  "action": {
    "default_popup": "src/popup/index.html"
  },
  "content_scripts": [{
    "matches": ["https://example.com/*"],
    "js": ["src/content/index.tsx"]
  }],
  "background": {
    "service_worker": "src/background/index.ts",
    "type": "module"
  },
  "permissions": ["storage", "activeTab"]
}

4. Content scripts i wstrzykiwanie Reacta na strony

Content scripts to najpotężniejsza część rozszerzeń Chrome. Działają w kontekście stron internetowych, co oznacza, że mogą czytać i modyfikować DOM dowolnej strony (z odpowiednimi uprawnieniami).

Wyzwaniem jest wstrzyknięcie pełnego drzewa komponentów React na istniejącą stronę bez jej zepsucia. Dokładnie to rozwiązuje nasza wewnętrzna biblioteka react-content-script-injector:

Statyczne strony to łatwy przypadek - wstrzykujesz raz i gotowe. Trudna część to aplikacje React i SPA, gdzie DOM ciągle się zmienia, adresy zmieniają się bez przeładowania strony, a aplikacja hosta może testować A/B warianty, które przesuwają lub zmieniają elementy, do których celujesz. W tym się specjalizujemy i dlatego zbudowaliśmy tę bibliotekę.

5. Shadow DOM: izolacja stylów, która działa

Izolacja stylów to największy problem w developmencie content scriptów. Bez niej UI rozszerzenia dziedziczy style strony hosta - przyciski wyglądają źle, fonty się zmieniają, spacing się psuje. I odwrotnie - CSS rozszerzenia może przypadkowo zmienić wygląd strony hosta.

Shadow DOM zapewnia prawdziwą enkapsulację. Style wewnątrz shadow root nie wyciekają na zewnątrz, a style z zewnątrz nie wchodzą do środka. To krytyczne dla produkcyjnych rozszerzeń, które muszą działać na tysiącach różnych stron z różnymi resetami CSS, frameworkami i konfliktującymi nazwami klas.

Nasz react-content-script-injector obsługuje setup Shadow DOM automatycznie, włącznie z trudnymi częściami: wstrzykiwaniem Tailwinda do shadow root, ładowaniem fontów przez granicę shadow i prawidłowym działaniem portali (modale, dropdowny) w kontekście shadow. Ponieważ biblioteka natywnie zarządza React Portals, pełen React context - providery, stan, motyw - pozostaje dostępny wewnątrz każdego portalu, więc komponenty renderowane w Shadow DOM zachowują się dokładnie jak komponenty w normalnym drzewie React.

6. Komunikacja między kontekstami

Rozszerzenie Chrome ma wiele izolowanych kontekstów JavaScript: content script (działa na stronach), background service worker, popup i strony opcji. Komunikują się przez Chrome messaging API.

W praktyce wychodzi wzorzec podobny do architektury klient-serwer: service worker jest Twoim "serwerem" (obsługuje wywołania API, storage i logikę biznesową), a content scripts i popup to "klienci", którzy żądają danych i wyzwalają akcje.

Z TypeScriptem możesz sprawić, że komunikacja będzie w pełni typowo-bezpieczna: wiadomość typu "GET_PRICES" zawsze zwraca typowaną odpowiedź PriceData. To eliminuje całą klasę błędów runtime, które są trudne do debugowania między kontekstami.

// messages.ts - Define typed message schemas
type MessageMap = {
  GET_PRICES: {
    request: { productId: string };
    response: { prices: number[]; currency: string };
  };
  UPDATE_SETTINGS: {
    request: { theme: 'light' | 'dark' };
    response: { success: boolean };
  };
};

// Type-safe sender (content script or popup)
async function sendMessage<T extends keyof MessageMap>(
  type: T,
  payload: MessageMap[T]['request']
): Promise<MessageMap[T]['response']> {
  return chrome.runtime.sendMessage({ type, payload });
}

// Usage - fully typed, autocomplete works
const { prices } = await sendMessage('GET_PRICES', {
  productId: 'sku-123'
});

7. Storage i zarządzanie stanem

Rozszerzenia mają własne API storage: chrome.storage.local dla danych lokalnych na urządzeniu i chrome.storage.sync dla danych, które podążają za użytkownikiem między urządzeniami. W przeciwieństwie do localStorage, są dostępne we wszystkich kontekstach rozszerzenia.

Dla złożonego stanu używamy lekkiego wzorca reaktywnego store: service worker trzyma źródło prawdy, a content scripts subskrybują zmiany przez chrome.storage.onChanged. Daje to synchronizację w czasie rzeczywistym między wszystkimi otwartymi kartami bez dodatkowej infrastruktury.

Ważne zastrzeżenie: chrome.storage.sync ma ścisłe limity rozmiaru (102 400 bajtów łącznie, 8 192 bajtów na element). Dla większych zbiorów danych używaj chrome.storage.local i obsłuż synchronizację między urządzeniami samodzielnie.

// content-script.ts - Subscribe to storage changes
chrome.storage.onChanged.addListener((changes, area) => {
  if (area === 'local' && changes.userSettings) {
    const newSettings = changes.userSettings.newValue;
    // React component re-renders automatically
    updateUI(newSettings);
  }
});

// service-worker.ts - Write once, all tabs update
await chrome.storage.local.set({
  userSettings: { theme: 'dark', language: 'en' }
});
// Every open tab receives the change event instantly

8. Wdrożenie i dystrybucja

Istnieją cztery główne kanały dystrybucji rozszerzeń Chrome:

Obsługujemy cały pipeline wdrożenia: build, pakowanie, przesłanie i iterację na feedbacku z weryfikacji. Nasze CI/CD automatycznie podbija wersje rozszerzenia i paczek, buduje artefakt i wdraża bezpośrednio na Chrome Web Store - dzięki czemu każdy merge do main to potencjalny release. Dla testerów ten sam pipeline publikuje instalowalne buildy na GitHub. Dla klientów enterprise dodajemy dystrybucję przez Group Policy. Więcej o tym, jak to ustawiamy, przeczytasz w naszym artykule o CI/CD dla rozszerzeń.

9. Najczęstsze błędy, które widzieliśmy

Po zbudowaniu i przeglądzie dziesiątek rozszerzeń, to są wzorce, które powodują najwięcej problemów:

10. Najczęściej zadawane pytania

Powiązane artykuły