Why donate
API Explorer
Upgrade guide
The quasar.config file
Convert project to CLI with Vite
Browser Compatibility
Supporting TypeScript
Directory Structure
Commands List
CSS Preprocessors
Lazy Loading - Code Splitting
Handling Assets
Boot Files
Prefetch Feature
API Proxying
Handling Vite
Handling process.env
State Management with Pinia
State Management with Vuex
Testing & Auditing
Developing Mobile Apps
Ajax Requests
Opening Dev Server To Public
Quasar CLI with Vite - @quasar/app-vite
Configuring BEX

Before we can configure anything, we need to understand how the BEX is structured. A BEX can be one (or more) of the following:

  1. Runs in its own tab in the browser
  2. Runs in the Developer Tools window.
  3. Runs in a Popup window.
  4. Runs as Options window.
  5. Runs in the context of a web page (injected into a website)

You do not need a new Quasar App per BEX type above as a single Quasar Application can run in all of the instances above. You can find out more about these in the types section.

UI in /src

Should you want to tamper with the Vite config for UI in /src:

/quasar.config file

module.exports = function (ctx) {
  return {
    build: {
      extendViteConf (viteConf) {
        if (ctx.mode.bex) {
          // do something with ViteConf

The UI files will be injected and available as www folder when you build (or develop) the browser extension.


The most important config file for your BEX is /src-bex/manifest.json. It is recommended that you read up on this file before starting your project.

When you first add the BEX mode, you will get asked which Browser Extension Manifest version you like:

? What version of manifest would you like? (Use arrow keys)
❯ Manifest v2 (works with both Chrome and FF)
  Manifest v3 (works with Chrome only currently)

Background And Content Scripts

Behind every BEX is a content script and a background script / service-worker. It’s a good idea to understand what each of these are before writing your first BEX.

In summary:

  • Background Script - runs in the context of the BEX itself and can listen to all available browser extension events. There will only ever be one instance of each background script per BEX.
  • Content Script - runs in the context of the web page. There will be a new content script instance per tab running the extension.


Given content scripts run in the web page context, this means that only BEX’s that interact with a web page can use content scripts. Popups, Options and Devtools will not have a content script running behind them. They will all however have a background script.


Service worker which is available in Manifest v3, is implemented in Quasar CLI with Vite only. More details here.


Any styles you want to be made available to your web page (not your Quasar App) should be included in src-bex/assets/content.css as this file ia automatically injected into the manifest.json file.


This must be native CSS as it’s not preprocessed via Sass.