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
Fetching Data
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 application. Service workers require a secure context; use HTTPS in production. Browsers treat http://localhost as potentially trustworthy, so local Quasar development does not normally require 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 package to package.json as a dependency if it is not already installed.

/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

If you access the development server through a hostname that the browser does not consider trustworthy, use HTTPS. The available options include:

  • access it through http://localhost:<port> or http://127.0.0.1:<port> when developing on the same machine; browsers treat these origins as potentially trustworthy
  • set quasar.config file > devServer > https: true
  • when testing through a LAN address, custom hostname, or another device, serve your development server through an HTTPS tunnel such as tunnelmole, localhost.run or ngrok

Here is a tunnelmole example. Install it first:


pnpm add --global 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" }]
      }
    ]
  }
}