Quasar makes use of some awesome development tools under its hood, like Webpack. One of the great things about Quasar is its handling of most of the complex configuration needed by the underlying tools for you. As a result, you don’t even need to know Webpack or any of the other development tools in order to use Quasar.

So what can you configure through /quasar.conf.js?

• Quasar components, directives and plugins that you’ll be using in your website/app
• Default Quasar Language Pack
• Icon libraries that you wish to use
• Default Quasar Icon Set for Quasar components
• Development server port, HTTPS mode, hostname and so on
• CSS animations that you wish to use
• Boot Files list (that determines order of execution too) – which are files in /src/boot that tell how your app is initialized before mounting the root Vue component
• Global CSS/Stylus/… files to be included in the bundle
• PWA manifest and Workbox options
• Electron Packager and/or Electron Builder
• IE11+ support
• Extend Webpack config

Structure

The basics

You’ll notice that /quasar.conf.js exports a function that takes a ctx (context) parameter and returns an Object. This allows you to dynamically change your website/app config based on this context:

module.exports = function (ctx) { // can be async too (@quasar/app v2.1+)
  console.log(ctx)

  // Example output on console:
  {
    dev: true,
    prod: false,
    mode: { spa: true },
    modeName: 'spa',
    target: {},
    targetName: undefined,
    arch: {},
    archName: undefined,
    debug: undefined
  }

  // context gets generated based on the parameters
  // with which you run "quasar dev" or "quasar build"
}

What this means is that, as an example, you can load a font when building for a certain mode (like PWA), and pick another one for the others:

module.exports = function (ctx) {
  extras: [
    ctx.mode.pwa // we're adding only if working on a PWA
      ? 'roboto-font'
      : null
  ]
}

Or you can use a global CSS file for SPA mode and another one for Cordova mode while avoiding loading any such file for the other modes.

module.exports = function (ctx) {
  css: [
    ctx.mode.spa ? 'app-spa.styl' : null, // looks for /src/css/app-spa.styl
    ctx.mode.cordova ? 'app-cordova.styl' : null  // looks for /src/css/app-cordova.styl
  ]
}

Or you can configure the dev server to run on port 8000 for SPA mode, on port 9000 for PWA mode or on port 9090 for the other modes:

module.exports = function (ctx) {
  devServer: {
    port: ctx.mode.spa
      ? 8000
      : (ctx.mode.pwa ? 9000 : 9090)
  }
}

Also, starting with “@quasar/app” v2.1+, you can now do async work before returning the quasar configuration:

module.exports = async function (ctx) {
  const data = await someAsyncFunction()
  return {
    // ... use "data"
  }
}

// or:
module.exports = function (ctx) {
  return new Promise(resolve => {
    // some async work then:
    // resolve() with the quasar config
    resolve({
      //
    })
  })
}

The possibilities are endless.

IDE autocompletion

Starting with v1.9, you can wrap the returned function with configure() helper to get a better IDE autocomplete experience (through Typescript):

const { configure } = require('quasar/wrappers')

module.exports = configure(function (ctx) {
  /* configuration options */
})

Options to Configure

Let’s take each option one by one:

Property: css

Global CSS/Stylus/… files from /src/css/, except for theme files, which are included by default.

// quasar.conf.js
return {
  css: [
    'app.styl', // referring to /src/css/app.styl
    '~some-library/style.css' // referring to node_modules/some-library/style.css
  ]
}

Property: vendor

By default, everything that comes from node_modules will be injected into the vendor chunk for performance & caching reasons. However, should you wish to add or remove something from this special chunk, you can do so:

// quasar.conf.js
return {
  vendor: {
    /* optional; @quasar/app v1.4.2+;
       disables vendor chunk: */ disable: true,

    add: [ 'src/plugins/my-special-plugin' ],
    remove: ['axios', 'vue$']
  }
}

Property: framework

@quasar/app v2 specs

Tells the CLI what Quasar components/directives/plugins to import, what Quasar I18n language pack to use, what icon set to use for Quasar components and more.

Filling “components” and “directives” is required only if “all” is set to false.

// quasar.conf.js
return {
  // a list with all options (all are optional)
  framework: {
    // Possible values for "importStrategy":
    // * 'auto' - Auto-import needed Quasar components & directives
    // * 'all'  - Import everything from Quasar
    //            (not treeshaking Quasar; biggest bundle size)
    importStrategy: 'auto',

    // is using "auto" import strategy, you can also configure:
    autoImportComponentCase: 'pascal', // or 'kebab' (default) or 'combined'

    // For special cases outside of where auto-import "auto" can have an impact
    // (like functional components as one of the examples),
    // you can manually specify Quasar components/directives to be available everywhere:
    //
    // components: [],
    // directives: [],

    // Quasar plugins
    plugins: ['Notify' /* ... */],

    // Quasar config
    // You'll see this mentioned for components/directives/plugins which use it
    config: { /* ... */ },

    iconSet: 'fontawesome-v6', // requires icon library to be specified in "extras" section too,
    lang: 'de', // Tell Quasar which language pack to use for its own components

    cssAddon: true // Adds the flex responsive++ CSS classes (noticeable bump in footprint)
  }
}

More on cssAddon here.

Property: devServer

Webpack devServer options. Take a look at the full list of options. Some are overwritten by Quasar CLI based on “quasar dev” parameters and Quasar mode in order to ensure that everything is setup correctly. Note: if you’re proxying the development server (i.e. using a cloud IDE), set the public setting to your public application URL.

Most used properties are:

Using open prop to open with a specific browser and not with the default browser of your OS (check supported values based on the host OS):

// quasar.conf.js

devServer: {
  open: 'firefox'
}

When you set devServer > https: true in your quasar.conf.js file, Quasar will 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.conf.js > devServer > https should look like this:

// quasar.conf.js

const fs = require('fs')
// ...

devServer: {
  https: {
    key: fs.readFileSync('/path/to/server.key'),
    cert: fs.readFileSync('/path/to/server.crt'),
    ca: fs.readFileSync('/path/to/ca.pem'),
  }
}

Starting with @quasar/app v1.3.2, you can also configure automatically opening remote Vue Devtools:

// quasar.conf.js

devServer: {
  vueDevtools: true
}

Docker and WSL Issues with HRM

If you are using a Docker Container, you may find HMR stops working. HMR relies on the operating system to give notifications about changed files which may not work for your Docker Container. You can change this to polling by adding:

devServer: {
  watchOptions: {
    poll: 1000
  }
}

Property: build

@quasar/app v2 specs

The following properties of build are automatically configured by Quasar CLI depending on dev/build commands and Quasar mode. But if you like to override some (make sure you know what you are doing), you can do so:

If, for example, you run “quasar build --debug”, sourceMap and extractCSS will be set to “true” regardless of what you configure.

Property: htmlVariables

@quasar/app v2 specs

You can define and then reference variables in src/index.template.html, like this:

// quasar.conf.js
module.exports = function (ctx) {
  return {
    htmlVariables: {
      title: 'test name',
      some: {
        prop: 'my-prop'
      }
    }

Then (just an example showing you how to reference a variable defined above, in this case title):

<!-- src/index.template.html -->
<%= title %>
<%= some.prop %>

Property: sourceFiles

Use this property to change the default names of some files of your website/app if you have to. All paths must be relative to the root folder of your project.

// default values:
sourceFiles: {
  rootComponent: 'src/App.vue',
  router: 'src/router',
  store: 'src/store',
  indexHtmlTemplate: 'src/index.template.html',
  registerServiceWorker: 'src-pwa/register-service-worker.js',
  serviceWorker: 'src-pwa/custom-service-worker.js',
  electronMainDev: 'src-electron/main-process/electron-main.dev.js',
  electronMainProd: 'src-electron/main-process/electron-main.js'
}

Example setting env for dev/build

@quasar/app v2 specs

There’s two concepts that need to be understood here. The env variables from the terminal that are available in /quasar.conf.js file itself and the environment variables that you pass to your UI code.

// quasar.conf.js

// Accessing terminal variables
console.log(process.env)

module.exports = function (ctx) {
  return {
    // ...

    build: {
      // passing down to UI code from quasar.conf.js
      env: {
        API: ctx.dev
          ? 'https://dev.api.com'
          : 'https://prod.api.com'
      }
    }
  }
}

Then in your website/app you can access process.env.API and it’s gonna point to one of those two links above, based on dev or production build type.

You can even go one step further. Supply it with values taken from the quasar dev/build env variables:

# we set an env variable in terminal
$ MY_API=api.com quasar build

# then we pick it up in /quasar.conf.js
build: {
  env: {
    API: ctx.dev
      ? 'https://dev.' + process.env.MY_API
      : 'https://prod.' + process.env.MY_API
  }
}

Using dotenv

Should you wish to use .env file(s), you can even use dotenv package. The following is just an example that passes env variables from the terminal right down to your UI’s app code:

$ yarn add --dev dotenv

Then in your /quasar.conf.js:

build: {
  env: require('dotenv').config().parsed
}

Handling Webpack configuration

In depth analysis on Handling Webpack documentation page.