Fehlerbehebung und Logging

Fehler in einem Service Worker zu beheben, ist mühsam. Es geht um den Lebenszyklus, Updates, Caches und die Interaktion zwischen all diesen Dingen. Zum Glück erleichtert Workbox durch die informative Protokollierung nicht nur die Entwicklung von Service Workern, sondern auch das Debugging. Auf dieser Seite werden einige der verfügbaren Debugging-Tools erläutert. Außerdem erfahren Sie, wie die Protokollierung von Workbox funktioniert und wie sie konfiguriert werden kann.

Verfügbare Tools zur Fehlerbehebung

Im Browser stehen zahlreiche Tools für die Fehlerbehebung und Fehlerbehebung während der Entwicklung eines Service Workers zur Verfügung. Hier finden Sie einige Ressourcen, die Ihnen den Einstieg in den Browser Ihrer Wahl erleichtern.

Chrome und Edge

Chrome (und aktuelle Versionen von Edge, die auf der Blink-Engine basieren) bieten eine robuste Auswahl an Entwicklertools. Einige dieser Tools – insbesondere in den Entwicklertools von Chrome – wurden in dieser Dokumentation bereits erwähnt, es gibt jedoch noch mehr zu entdecken:

Firefox

Firefox-Nutzer können die folgenden Ressourcen zurate ziehen:

Safari

Safari verfügt derzeit über eine eingeschränktere Auswahl an Entwicklertools für das Debugging von Service Workern. In den folgenden Ressourcen erfahren Sie mehr über sie:

Workbox-Protokollierung

Eine wichtige Verbesserung von Workbox ist die informative Protokollierung. Wenn die Protokollierung aktiviert ist, protokolliert Workbox fast alle Aktivitäten auf charakteristische und funktionale Weise.

Screenshot der Workbox-Protokollmeldungen in der Konsole der Chrome-Entwicklertools. Die Protokollierungsmeldungen werden von normalen Konsolenprotokollen durch ein Workbox-Logo unterschieden. Jede Nachricht kann erweitert werden, um weitere Debugging-Informationen zu erhalten.

Bei Entwicklungs-Builds von Workbox ist die Protokollierung standardmäßig aktiviert, während sie bei Produktions-Builds deaktiviert wird. Es gibt verschiedene Schritte für den Wechsel zwischen Entwicklungs- und Produktions-Builds, je nachdem, ob du ein benutzerdefiniertes Workbox-Bundle erstellen oder eine vorab gebündelte Kopie über workbox-sw verwenden möchtest.

Mit oder ohne Bundler

Bundler sind Tools, die Code aus einzelnen Modulen abrufen und JavaScript-Ausgaben erstellen, die direkt im Browser ausgeführt werden können. Wenn Sie einen Bundler verwenden, können Sie auch ein Bundler-spezifisches Workbox-Plug-in verwenden, das das Precaching unterstützt, wie workbox-webpack-plugin, oder Sie bündeln einfach nur Workbox-Laufzeit-Caching-Logik. In beiden Fällen wird das Logging von Workbox durch die Festlegung eines Produktionsmodus in der Bundler-Konfiguration beeinflusst:

  • Im Webpack kann die Konfigurationsoption mode auf 'production' oder 'development' festgelegt werden. workbox-webpack-plugin verwendet das Produktions- oder Entwicklungs-Logging in Workbox anhand dieses Werts.
  • Für Rollup akzeptiert rollup-plugin-workbox eine mode-Konfigurationsoption, die sich auch darauf auswirkt, ob Workbox etwas in der Konsole protokolliert. Wenn Sie Rollup ohne das Workbox-spezifische Plug-in verwenden, müssen Sie @rollup/plugin-replace so konfigurieren, dass process.env.NODE_ENV durch 'development' oder 'production' ersetzt wird.

Angenommen, das Standard-Logging-Verhalten muss in der Entwicklung überschrieben werden. In diesem Fall sollte es Ihnen mit dem entsprechenden Workbox-Plug-in für Ihren Bundler möglich sein, eine Einstellung für Debugging-Protokolle in seiner Konfiguration hartzucodieren. Sie können beispielsweise die Protokollierung in Workbox über die Option mode von workbox-webpack-plugin für die Methode GenerateSW deaktivieren.

Ohne Bundler

Bundler sind zwar großartig, aber nicht jedes Projekt benötigt sie. Wenn Sie Workbox einem Projekt hinzufügen möchten, das keinen Bundler verwendet, sollten Sie workbox-sw verwenden.

Das Modul workbox-sw vereinfacht das Laden anderer Workbox-Module (z.B. workbox-routing, workbox-precaching usw.) von einem CDN. Ob die Entwicklungs- oder Produktions-Bundles geladen werden, hängt von der URL ab, die für den Zugriff auf Ihre Webanwendung verwendet wird. Standardmäßig lädt workbox-sw die Entwicklungsversion von Workbox, wenn Ihre Web-App unter http://localhost ausgeführt wird, und sonst die Produktionsversion.

Sie können das Standardverhalten überschreiben, indem Sie die Methode setConfig von Workbox aufrufen, um die Option debug auf true festzulegen:

// Load workbox-sw from a CDN
importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.2.0/workbox-sw.js');

// This must come before any other workbox.* methods.
workbox.setConfig({
  debug: true
});

// Now use workbox.routing.*, workbox.precaching.*, etc.

Logging in Entwicklungs-Builds in beliebigen Workflows deaktivieren

Unabhängig davon, ob Sie einen Bundler verwenden oder nicht, können Sie das Logging in Entwicklungs-Builds deaktivieren. Dazu weisen Sie Ihrem Service Worker true einer speziellen self.__WB_DISABLE_DEV_LOGS-Variable zu:

//
self.__WB_DISABLE_DEV_LOGS = true;

// The rest of your Workbox service worker code goes here

Ein Vorteil dieses Ansatzes besteht darin, dass er vollständig unabhängig von Ihrer Bundler-Konfiguration ist und unabhängig davon funktioniert, ob Sie workbox-sw direkt verwenden oder einen Bundler für die Paketerstellung Ihres Service Workers auf Workbox benötigen.

Weitere Informationen

Wenn Sie immer noch Schwierigkeiten haben, herauszufinden, was bei einem fehlerhaften Service Worker vor sich geht und die Protokollierung nicht ausreicht, können Sie eine Frage auf Stack Overflow mit dem Tag workbox posten. Wenn Sie dort keine Antwort finden, melden Sie ein GitHub-Problem, nachdem Sie die Beitragsrichtlinien gelesen haben. So kann nicht nur eine breite Zielgruppe von Entwicklern Ihre Fragen lesen und beantworten, auch die Antwort auf Ihre Frage kann jemandem in der gleichen Situation helfen.