Configuring quasar.conf.js     

Quasar Starter Kit makes use of some awesome tools under the cover, like Webpack. Fortunately, the complexity of configuring the underlying tools is managed by Quasar CLI which does the heavy lifting for you. As a result, you don’t even need to know Webpack 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 I18n language pack
• Icon pack(s) that you wish to use
• Default icon set for Quasar components
• Development server port, HTTPS mode, hostname and so on
• CSS animations that you wish to use
• App Plugins list (that determines order of execution too) – which are files in /src/plugins that tell how your app is initialized before mounting the root Vue component
• Global CSS/Stylus/… files to be included in the bundle
• What should be added or removed from “vendor” chunk
• PWA manifest
• Electron Packager
• IE11+ support
• Extend Webpack config Object

You’ll notice that changing any of these settings does not require you to manually reload the dev server. Quasar detects if the changes can be injected through Hot Module Reload and in case it can’t, it will reload the dev server for you. You won’t lose your development flow as you will just sit back while Quasar CLI quickly takes care of it.

/quasar.conf.js is run by the Quasar CLI build system, so this code runs under Node directly, not in the context of your app. So you can require modules like ‘fs’, ‘path’, ‘webpack’ and so on. Make sure the ES6 features that you want to write this file with are supported by the installed version of your Node (which should be >= 8.9.0).

Structure

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) {
  console.log(ctx)

  // Example output on console:
  {
    dev: true,
    prod: false,
    theme: { mat: true },
    themeName: 'mat',
    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 with Quasar Material theme, and pick another one for Quasar iOS theme.

module.exports = function (ctx) {
  extras: [
    ctx.theme.mat
      ? 'roboto-font' // we're building with Material theme
      : null // we're not building with Material theme, so it's iOS theme
  ]
}

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)
  }
}

The possibilities are endless.

Options to Configure

Let’s take each option one by one:

DevServer Property

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.

Most used properties are:

Build Property

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.

Example setting env for dev/build

build: {
  env: ctx.dev
    ? { // so on dev we'll have
      API: JSON.stringify('https://dev.api.com')
    }
    : { // and on build (production):
      API: JSON.stringify('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: ctx.dev
    ? { // so on dev we'll have
      API: JSON.stringify('https://dev.'+ process.env.MY_API)
    }
    : { // and on build (production):
      API: JSON.stringify('https://prod.'+ process.env.MY_API)
    }
}

Extending Webpack Config Object

This is achieved through build > extendWebpack() Function. Example adding a Webpack loader.

// quasar.conf.js

build: {
  extendWebpack (cfg) {
    // we make in-place changes
    cfg.modules.rules.push({
      test: /\.json$/,
      loader: 'json-loader'
    })

    // no need to return anything
  }
}

Adding your own alias to Webpack

To add your own alias you can extend the webpack config and merge it with the existing alias.
Use the path.resolve helper to resolve the path to your intended alias.

// quasar.conf.js

build: {
  extendWebpack (cfg) {
   cfg.resolve.alias = {
    ...cfg.resolve.alias, // This adds the existing alias

    // Add your own alias like this
    myalias: path.resolve(__dirname, './src/somefolder'),
  }
}