Developing Electron Apps

Misc

Configuring quasar.conf.js

Quasar makes use of some awesome development tools under it’s 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.

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 Replacement and in case it can’t, it will reload the dev server automatically for you. You won’t lose your development flow, because you can just sit back while Quasar CLI quickly reloads the changed code, even keeping the current state. This save tons of your time!

/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. This means 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:

Webpack dev server options. Some properties are overwritten based on the Quasar mode you’re using in order to ensure a correct config. Note: if you’re proxying the development server (i.e. using a cloud IDE), set the public setting to your public application URL.

vendor Property

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:

devServer Property

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:

Property

Type

Description

port

Number

Port of dev server

host

String

Local IP/Host to use for dev server

open

Boolean

Open up browser pointing to dev server address automatically. Applies to SPA, PWA and SSR modes.

public

String

Public address of the application (for use with reverse proxies)

build Property

Property

Type

Description

transpileDependencies

Array of Regex

(CLI v0.17.6+) Add dependencies for transpiling with Babel (from node_modules, which are by default not transpiled). Example: [ /my-dependency/, ...]

showProgress

Boolean

(CLI v0.17+) Show a progress bar while compiling.

extendWebpack(cfg)

Function

Extend Webpack config generated by Quasar CLI. Equivalent to chainWebpack(), but you have direct access to the Webpack config object.

Public path of your app. By default, it uses the root. Use it when your public path is something else, like “<protocol>://<domain>/some/nested/folder” – in this case, it means the distributables are in “some/nested/folder” on your webserver.

Folder where Quasar CLI should generate the distributables. Relative path to project root directory. Default is ‘dist/{ctx.modeName}-{ctx.themeName}’. Applies to all Modes except for Cordova (which is forced to src-cordova/www).

(v0.16+) Default is “true”. Preload chunks when browser is idle to improve user’s later navigation to the other pages.

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 you are using Quasar CLI v0.16.2+, then you have another method to tamper with the generated Webpack config, through build > chainWebpack(chain). The difference is that it is easier because you’ll be using webpack-chain to do it.