Open manniL opened 8 months ago
Can you share more context in what common usecases this might be useful to use something different from NODE_ENV
?
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.
In addition to @fmoessle's comment, build
sets the NODE_ENV always to production
, leaving no room for further options.
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.
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? 👀 https://github.com/nuxt/cli/blob/5cdb2f5b29efaacbf8e52b15ab14eab51a1b647e/src/utils/env.ts#L5
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.
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.
And allow to use environment overrides for all custom environments (ex: staging)
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
?
I need this ability for my deployment, so, to have easier access to my fork, I temporarily published it in the Github registry. If anybody is interested, you can install it from there and give it a spin: npm install @tillsanders/nuxt-cli@3.11.2
. Make sure to add @tillsanders:registry=https://npm.pkg.github.com/
to your .npmrc
and sign in to Github (npm login --auth-type=legacy --registry=https://npm.pkg.github.com
).
I just tried @tillsanders PR and it works really well in our use case! We currently develop a multistore environment within Nuxt and use layers as different themes. We could then use the env-specific config for production, staging and local development.
Can we have the PR merged? Or what is missing here? @pi0
Right now we only have one option when deploying (which uses nuxt build
): Environment is "production". It cant be set to preview
, staging
, develop
or anything else when deploying/building.
Meanwhile nuxt.config.ts
provides us with a very convenient way to override values for specific environments:
$production: {
ignore: ['app/pages/dev'],
scripts: {
registry: {
cloudflareWebAnalytics: true,
},
},
},
$preview: {
ignore: ['app/pages/dev'],
},
But this is kinda useless because NODE_ENV
cant be set to anything else than production
. So in the example above even in the preview deployment the cloudflare web analytics are loaded.
Just to keep everyone in the loop: There was some feedback to my PR which I have now addressed. Mainly, the flag has been renamed from --env
to --envName
. If you want to try that as well, please use @tillsanders/nuxt-cli@3.11.3
(see above).
I have also made a small change to the documentation, here: https://github.com/nuxt/nuxt/pull/28909
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 theenvName
value, e.g. by patching the CLI or similar, it would be nice to have some kind of flag which changes theenvName
to a different env variable, such asTARGET
,APP_ENV
etc.