The env variables loaded from .env file cannot be used inside quasar.config file

[yusufkandemir]

app-vite v2 / app-webpack v4 added automatic .env file loading feature. Before that, the developers were encouraged to manually load env variables using dotenv at the top of quasar.config file, allowing process.env.* to be used anywhere inside the config file. However, with Quasar’s new built-in env handling, env variables are only injected into the app code (src/*), not quasar.config.*.

Due to this, cases like the following will not work out of the box:

// quasar.config.js
import { defineConfig } from '#q-app/wrappers'

export default defineConfig({
  build: {
    analyze: process.env.ANALYZE === 'true'
  },
  devServer: {
    proxy: {
      '/api': {
        target: process.env.API_URL,
        changeOrigin: true
      }
    }
  }
})

The user will have to use dotenv at the top of the file as before, rendering the new feature useless for them.

Additional Case

Anyone using Docker, CI/CD, or any other environment where the env variables are provided externally, rather than in a .env file, will have to specify the variables in quasar.config file > build > env like FOO: process.env.FOO to use them in the app code. This is another case where the new feature is meaningless due to the requirement of specifying the variables manually.

To make matters worse, since the variables are not available inside the config file, user's manual mapping will result in all variables being undefined. This will cause the values from the env file to get overridden with undefined values. So, the user will have to manually load the env file using dotenv anyway, making the new feature useless for them. Example:

// quasar.config.js
export default defineConfig({
  build: {
    env: {
      // This will work fine when in Docker, CI/CD, etc.
      // But, it will be undefined when running locally.
      // Since build > env overrides the values from .env file, the .env file will be useless.
      // So, the user will have to use dotenv to load the env file as before.
      FOO: process.env.FOO
    }
  }
})

The Chicken and Egg Problem

Quasar checks quasar.config file > build > envFolder/envFiles/envFilter for deciding on what/how to load the env files. So, to be able to use the env variables inside the config file, Quasar must process the config file first. But, to be able to process the config file, Quasar must load the env files first. This creates a chicken and egg problem. So, it's not straightforward to add this feature.

So, it can only be achieved by not respecting envFolder/envFiles/envFilter during the config file processing. This could be confusing for users which use those options. So, the limitations must be documented clearly. The env variables will be loaded according to the default load order, e.g. .env, .env.local, etc.

Proposed Solutions

1. Add a note to the migration guide: The migration guide should mention that the env variables are not available inside the config file and that users will have to use dotenv at the top of the file as before.
2. Add a note to the documentation: The documentation should mention that the env variables are not available inside the config file and that users will have to use dotenv at the top of the file as before.
3. Add an option to preload the env variables: Add an option like preloadEnv to opt-in to load the env variables before processing the config file. This will allow users to use the env variables inside the config file without having to use dotenv at the top of the file. The limitations of this feature must be documented clearly.

• If this happens without a flag, anyone using dotenv or some other mechanism may face unexpected behavior.
• It would be a good idea to make this the new "recommended default" by scaffolding the option set to true in newly created projects and update the docs accordingly.

4. Future behavior: In the future, this "preloading" behavior can be made the default behavior while making envFolder/envFiles/envFilter options as advanced and with the necessary warnings.