Why donate
API Explorer
Upgrade Guide
Creating a New Project
The /quasar.config File
Convert q/app-webpack Project
Browser Compatibility
TypeScript Support
Directory Structure
Commands List
CSS Preprocessors
Page Routing with VueRouter
Lazy Loading - Code Splitting
Handling Assets
Boot Files
Prefetch Feature
API Proxying
Handling Vite
Handling import.meta.env
State Management with Pinia
Lint and Format Code
Testing & Auditing
Developing Mobile Apps
Ajax Requests
Opening Dev Server To Public
Quasar CLI with Vite - @quasar/app-vite v3
Handling Service Worker

Here you’ll learn how to interact with the Service Worker from within your website/app space. Remember, service workers MUST be served over HTTPS.

It’s important to note that the Service Worker (which gets automatically generated by Workbox – or you’ve configured Quasar CLI to use your custom one) runs in a separate thread. You can however interact with it from app-space from within /src-pwa/register-sw file.

Interacting with Service Worker

Add the register-service-worker npm package in your package.json file as a dependency (if it’s not already there).

/src-pwa/register-sw file

import { register } from 'register-service-worker'

register(import.meta.env.QUASAR_SERVICE_WORKER_FILE, {
  ready(registration) {
    console.log('Service worker is active.')
  },

  registered(registration) {
    console.log('Service worker has been registered.')
  },

  cached(registration) {
    console.log('Content has been cached for offline use.')
  },

  updatefound(registration) {
    console.log('New content is downloading.')
  },

  updated(registration) {
    console.log('New content is available; please refresh.')
  },

  offline() {
    console.log('No internet connection found. App is running in offline mode.')
  },

  error(error) {
    console.error('Error during service worker registration:', error)
  }
})

TIP

This file is automatically bundled into your website/app by Quasar CLI because it is considered as part of app-space /src.

SSL certificate

You may notice in some dev environments, that Workbox will not load your service workers during quasar dev if you are not using HTTPS to serve - even on localhost. You may see that there are two scripts that can’t load. The Chrome browser console is relatively tight-lipped about this, but Firefox tells you what is going on. The three options you have are:

  • set quasar.config file > devServer > https: true
  • setup a loopback from localhost to 127.0.0.1 (but this is not without security implications)
  • serve your localhost over tunnelmole, localhost.run or ngrok and use the https address provided by them.

Here is a tunnelmole example (install it first with yarn global add tunnelmole or npm i -g tunnelmole):

$ tmole 80
http://b8ootd-ip-157-211-195-182.tunnelmole.com is forwarding to localhost:80
https://b8ootd-ip-157-211-195-182.tunnelmole.com is forwarding to localhost:80

# ...and use the HTTPS url shown in the output

When you set devServer > https: true in your quasar.config file, Quasar will instruct Vite to auto-generate a SSL certificate for you. However, if you want to create one yourself for your localhost, then check out this blog post by Filippo. Then your quasar.config file > devServer > https should look like this:

/quasar.config file

devServer: {
  https: {
    // Use ABSOLUTE paths or path.join(import.meta.dirname, './root/relative/path')
    // https://nodejs.org/api/https.html#https_https_createserver_options_requestlistener
    key: "/path/to/server.key",
    pfx: "/path/to/server.pfx",
    cert: "/path/to/server.crt",
    ca: "/path/to/ca.pem",
    passphrase: 'vite-dev-server' // do you need it?
  }
}

More info on Vite and HTTPS here.

Important Hosting Configuration

It’s important that you do not allow browsers to cache the Service Worker file (by default: sw.js). Because otherwise updates to this file or to your app might slip through the cracks for browsers that load the service-worker from cache.

This is why you must always make sure to add "Cache-Control": "no-cache" to the headers of sw.js file via your hosting service.

As an example how this is done for Google Firebase, you would add the following to the firebase.json configuration:

{
  "hosting": {
    "headers": [
      {
        "source": "/sw.js",
        "headers": [{ "key": "Cache-Control", "value": "no-cache" }]
      }
    ]
  }
}