Load nuxt config with different `envName` for env-specific configs

[TheAlexLichter]

Hey all 👋

c12 provides us with the amazing opportunity to add env-specific configs to the nuxt config (also covered in my video), therefore relying on NODE_ENV by default. While it is technically possible to change the envName value, e.g. by patching the CLI or similar, it would be nice to have some kind of flag which changes the envName to a different env variable, such as TARGET, APP_ENV etc.

[pi0]

Can you share more context in what common usecases this might be useful to use something different from NODE_ENV?

[fmoessle]

E.g. deploying a project in a staging environment. Here I want the NODE_ENV to be "production" but need some other variable to differentiate between staging and production. We currently use process.env.TARGET for that and manually select and merge custom config-files depending on process.env.TARGET.

We are not the only ones facing this issue (https://www.youtube.com/watch?v=sCzO4fpKOW4) but it's possible I just don't get how to solve this in a more nuxt-fashioned way.

[TheAlexLichter]

In addition to @fmoessle's comment, build sets the NODE_ENV always to production, leaving no room for further options.

[pi0]

In addition to @fmoessle's comment, build sets the NODE_ENV always to production, leaving no room for further options.

This is a bug we might try to fix first.

[TheAlexLichter]

In addition to @fmoessle's comment, build sets the NODE_ENV always to production, leaving no room for further options.

This is a bug we might try to fix first.

I think this is intentional, isn't it? 👀

cli/src/utils/env.ts

Line 5 in 5cdb2f5

`Changing \`NODE_ENV\` from \`${currentEnv}\` to \`${targetEnv}\`, to avoid unintended behavior.`,

[fmoessle]

I think not using process.env.NODE_ENV with production when building the nuxt application is not a good idea. There are a lot of packages that behave differently when process.env.NODE_ENV is set to production (e.g. Node docs).

So as @manniL pointed out, process.env.NODE_ENV should not be used here.

[pi0]

I think this is intentional, isn't it? 👀

It is intentionally set because tools (notably postcss stuff) hardly depend on NODE_ENV==='production' to optimize properly. (@fmoessle you are right. only for clarification, I made that decision as well so I'm aware of it ;)

It is not intentional that we don't respect it for c12 configuration env.

[maximepvrt]

And allow to use environment overrides for all custom environments (ex: staging)

[tillsanders]

This would be a great help in supporting more than two environments. We, for example, have an additional demo environment for sales and a public beta environment that need differentiation (e.g. when it comes to CSP or the title template).

I also have a question though: would the environment-specific configuration be 'backed in' during build time or would it still be possible to change the environment when starting the build, for example like this: CUSTOM_ENV=demo node ./output/server/index.mjs?