0.5.0

This release includes 7 closed issues and 2 merged pull requests (aside from dependency updates). The two key changes are:

• ✨ Prevent service worker from varying by authentication state (and prevent auto-reloading). This is by far the most important update in this release, and it addresses some key pain points that have come to light with usage across the 30k+ active installs. #279, #205, #166, #202, #249, #223, #277
  1. When an updated service worker is activated, the window will not automatically reload.
  2. As soon as a service worker is installed, clients are now claimed by default; this makes sense to do since WordPress pages are not (normally) single-page-applications. In other words, a page accessed without a service worker is the same as a page served with a service worker (it's just the latter may be served from cache). If clients.claim() is not desired, it can be disabled via add_filter( 'wp_service_worker_clients_claim', '__return_false' ). This seems the best default for at least the 80% use case.
  3. Eliminate the “update site” link which was (rarely) shown. It was only shown when skip-waiting was disabled and if the admin bar was showing. Now skip-waiting is enabled and no reloading is being done, there is no need for this additional button. If a site wants to disable skip-waiting and add such a button, they can still do so. Again, it's removed since it's not deemed part in the 80% use case.
  4. Prevent the error templates for offline and 500 from being served with logged-in user state. Site owners should expect that that user-specific information should not be displayed on this page. This prevents the need for the service worker to update once logging-in or logging-out.
  5. In the same way, the service workers are also served with the user authentication being cleared to avoid serving user-specific information in the service worker. This also guards against the service worker varying by authentication state. This is somewhat similar to how the REST API behaves. Nevertheless, this may end up being an undesirable and we'll need to watch this for use cases. It could be useful to serve some auth key (e.g. REST API nonce) in the service worker, but this would end up being a pain as well once the key expires.
• 🐛 Prevent attempting to precache empty URLs which causes SW install failure. #271, #270

For a full list of issues and pull requests, see the 0.5 milestone. Compare all changes in 0.4.0...0.5.0.

Installation

Now available to install via WordPress.org.

You can also install the pwa.zip build linked below by uploading it in the WordPress admin.