Make env less surprising

[rotu]

process.env behaves confusingly in a Quasar Vite project.

In electron-main.js, process.env is an object that:

1. Has all string values.
2. Contains environment variables defined at build time.
3. Omits any definitions that have been declared in quasar.config.js.

This leads to the confusing situation that, e.g.:
process.env.DEV evaluates to true but the seemingly semantically identical code (null, process.env).DEV and eval(process.env.DEV) both evaluate to the runtime (string) value of the environment variable $DEV.

The issue is not as bad in frontend (Vue) code, since process is not defined.

The documentation also refers to Vite's built-in ".env", which is confusing since:

1. import.meta.env omits any variables defined in Quasar's config
2. Defines variables differently e.g. import.meta.env.MODE:"development" versus Quasar's process.env.MODE:'electron.

---

It would be nice if:

1. Environment variables didn't require assuming the node-specific process global, especially in the browser.
2. Environment variable access did not depend on magic syntax or if incorrect access failed in an obvious way (e.g. dynamic access should throw an error instead of giving the runtime value)
3. There were a documented relation between Quasar's env, Vite's env, the build variable environment, and the runtime variable environment

[rotu]

Another upshot is that if you import process from 'node:process', then references to process.env.MODE also refers to the live environment variable $MODE instead of the build-time value.

[rstoenescu]

Please follow #15303 (reply in thread)
Great improvements have already been implemented in next q/app* CLIs

[rotu]

I'm not sure how that resolves this. In fact, that's yet another definition of "env" which differs possibly from static defines of process.env.*, dynamic access to process.env, and import.meta.env.

What improvements have been made that make this less error-prone?

[dongwa]

I'm not sure how that resolves this. In fact, that's yet another definition of "env" which differs possibly from static defines of process.env.*, dynamic access to process.env, and import.meta.env.

What improvements have been made that make this less error-prone?

Maybe we can always make process.env.* equal to import.meta.env.*?

[rstoenescu]

Vite has the luxury of caring about fewer use-cases. Quasar CLI, on the other hand, supports lots of modes (Electron, BEX, etc etc) so the "env" needs to be standardized in some way. We chose process.env especially because of the familiarity for modes using Node.js and all the compiler threads (not just the UI one -- some modes have more than just the Vite thread) AND also to match the CLI with Webpack as much as possible (so developers can easily switch between CLI with Webpack and Vite). We are all for consistency, which is actually why we chose process.env which works across the board. So please, just use process.env and leave import.meta.env aside. You won't lose any functionality.

[rotu]

I would definitely move away from process.env for a couple reasons:

1. process.env.MODE already HAS a meaning - the value of the environment variable MODE. We don't set these environment variables at build time nor run time. Which was really confusing as I was logging process.env to debug and realizing that somehow process.env.MODE was unexpectedly not in there.
2. process.env.PROD is a string according to Node typings, but it's a bool according to compile-time substitutions.
3. import process from 'node:process' changes the meaning of process.env.MODE to the actual expected behavior, "breaking" Quasar's expectations.

It's great to have something consistent between build process and build targets. But this makes using process.env internally inconsistent. It "works across the board" until it doesn't. Even pretty benign-looking refactoring breaks the current setup.

---

Maybe it should be done as an unstructured injected global like __QUASAR_SSR_SERVER__ e.g. __QUASAR_ENV_MODE__.

Maybe as a structured injected constant like __QUASAR_ENV__.MODE (actually an object, not just something that looks superficially like a property access but breaks if you refactor the expression).

Maybe it should be importable magic: e.g. import { MODE } from '@quasar/env'.

Maybe it could be done as conditional exports (though this seems clunky, especially since it requires you to be importing across package boundaries).

---

What I really like about import.meta is that it's very clear that this is something injected by the build process which is the thing we want to convey here. Same with variables __THAT_LOOK_LIKE_THIS__.