Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dynamic runtime environment variables #5100

Open
janesser opened this issue Feb 24, 2019 · 82 comments
Open

dynamic runtime environment variables #5100

janesser opened this issue Feb 24, 2019 · 82 comments

Comments

@janesser
Copy link

@janesser janesser commented Feb 24, 2019

While striving for immutable build artifacts we came across some possible improvement points.

First let me explain the motivation behind "immutable build artifact". Alongside of the stages like e,g, DEV, TEST, QA, UAT, PROD the configuration changes, as an example nuxt-axios API_URL and API_BROWSER_URL. Ideally this can be injected by env vars, which pretty much fits the kubernetes way of dealing with configuration.

Presently a work-around can be achieved with help of https://github.com/samtgarson/nuxt-env, which does a decent job in providing needed injection mechanism. The down-side is that no nuxt-plugin by default goes for this.$env, which drives one in a lot of customizing of plugins. Not to mention the broken upgrade ease.

Can you imagine a way to support this natively in some of the next nuxt releases?

This question is available on Nuxt community (#c8719)
@pi0 pi0 transferred this issue from nuxt/rfcs Feb 24, 2019
@cmty cmty bot closed this Feb 24, 2019
@cmty cmty bot added the cmty:question label Feb 24, 2019
@pi0

This comment has been minimized.

Copy link
Member

@pi0 pi0 commented Feb 24, 2019

Hi @janesser. I've transferred issue from RFC to here because it is more an enhancement discussion.

Values passed to the env section of nuxt.config will be replaced by a webpack plugin during the build. Would you please elaborate more what you expect from storing it in build artifact?

@pi0 pi0 reopened this Feb 24, 2019
@nuxt nuxt deleted a comment from cmty bot Feb 24, 2019
@vhf

This comment has been minimized.

Copy link

@vhf vhf commented Feb 25, 2019

I also ran into this problem, here is one of my example case:

I'm using nuxtjs auth module with some OAuth API. Here is what the config looks like: https://auth.nuxtjs.org/reference/providers/github , in nuxt.config.js:

auth: {
  strategies: {
      github: {
        client_id: '...',

I'd like to build my app once and deploy it many times with different configuration values. This cannot be done because client_id: process.env.FOO_CLIENT_ID will be replaced at build time and the build-time value will be written in the build artifacts.

Here you couldn't build your app in a container and deploy it with different FOO_CLIENT_ID values, you would have to build the app each time you start a container.

I hope this makes the benefits of having nuxt projects configurable at runtime a bit clearer.

@aldarund

This comment has been minimized.

Copy link
Member

@aldarund aldarund commented Feb 25, 2019

@pi0 its more about have runtime env vars like in the module that is linked. E.g. build once deploy to different environments same artifact, isntead of building each time for each env ( e.g. staging, test, production etc )

@pi0

This comment has been minimized.

Copy link
Member

@pi0 pi0 commented Feb 25, 2019

I see the point. And auth and axios are probably best examples for such need. However, this is a duplicate topic and issue was discussed here is a short brief of status:

    1. process.env.* from server side is runtime configurable. axios module supports it for example for API_URL
    1. process.env.* from client-side when running in SSR mode, is only changeable if we somehow pass it to nuxtState. The simplest way would be using a store module.
    1. process.env.* from client-side when running in SPA or Static generated mode, is only changeable by doing an API call.

Having built-in support for case (2) could be possible but potentially opens a way to critical security holes and is only usable for SSR users.

Regarding case (3) also could be possible to store app config in a json file inside static dir and make client to download it on each visit. Has overhead but at least makes it somehow possible.

@pi0 pi0 changed the title nuxt envvar config dynamic runtime environment variables Feb 25, 2019
@janesser

This comment has been minimized.

Copy link
Author

@janesser janesser commented Feb 25, 2019

@pi0 can you link the original discussion that you refer too, please?

@vhf @aldarund thanks for supporting the need.

regarding the security, i am confident that docker envvars are sufficiently safe.
having something in javascript either hard-coded or dynamically refreshed is also in the same security class. Maybe i miss some attack vectors.

i felt like you hit the sensible point where it came to the way that webpack4 build routine is instrumented. Probably the present behaviour is at least partially inherited.

regarding possible solutions, did you check nuxt-env? by my experience it covers SSR plus non-SSR in a consistent way, not sure how it is solved internally. //cc @samtgarson
EDIT: it uses nuxtState around here: https://github.com/samtgarson/nuxt-env/blob/master/lib/plugin.js

ill try to collect some insight on webpack4 and eventually read through the internals of nuxt-env to give you some additional pointers.

@samtgarson

This comment has been minimized.

Copy link

@samtgarson samtgarson commented Feb 25, 2019

@janesser in the meantime open an issue for any confusing things you're hitting—I picked $env as it seemed appropriate but we can look at changing it or allowing it to be dynamic pretty easily.

@pi0 all I do is use a middleware to add the process.env values onto the req object, then a plugin which uses nuxtState to read from req and inject them onto the context.

Would be great to have this natively, it's currently impossible to use Nuxt in any kind of containerised, multi-environment setup with the existing native setup, or at least anywhere where the production environment could vary from the build environment.

@samtgarson

This comment has been minimized.

Copy link

@samtgarson samtgarson commented Feb 25, 2019

(non SSR and SPA are still scenarios that I don't think nuxt-env covers super smoothly, but it's OK...)

@pi0

This comment has been minimized.

Copy link
Member

@pi0 pi0 commented Feb 25, 2019

Mainly discussed in #618.

We are aware of @samtgarson nuxt-env project. That's implementing (2) method which would be useful for users that want it. It is more than qualified to be a nuxt-community project 👍

About security matter. Docker can't prevent one accidentally passing client_secrect to the user's browser window. It is the user's responsibility to be aware and ensure that.

/cc @manniL @aldarund

@janesser

This comment has been minimized.

Copy link
Author

@janesser janesser commented Feb 25, 2019

About secrets retention, check this one: samtgarson/nuxt-env#9

To wrap up, is there a way to make process.env as consumed by default from nuxt-plugins in the same way as process.$env?

@samtgarson

This comment has been minimized.

Copy link

@samtgarson samtgarson commented Feb 25, 2019

regarding secret env vars: nuxt-env supports these as of this PR but as @pi0 says, it's still up to the developer to ensure these don't get passed to the client.

Would be keen to help any efforts of integrating this or moving it over to nuxt-community, let me know if either of those are desired.

@axetroy

This comment has been minimized.

Copy link

@axetroy axetroy commented Feb 26, 2019

This is my solution:

set dynamic runtime environment variables in store

so we can get it in client side and server side via store.state.env.

// store/index.js

export const state = () => ({
  env: 'development'
})

export const actions {
  // run in every SSR
  async nuxtServerInit (store, context) {
    // read runtime environment everytimes and set to store
    const env = process.env.NODE_ENV || 'development'
    store.commit('SET_ENV', env)
  }
}

export const mutations = {
  SET_ENV (state, env) {
    state.env = env
  }
}

Use in middleware

// middleware/env.js

export default function ({store}) {
  console.log(store.state.env)
}

Use in page/layout/component

<template>
  <div>{{env}}</div>
</template>

<script>
export default {
  data () {
    return {
      env: this.$store.state.env
    }
  }
}
</script>
@janesser

This comment has been minimized.

Copy link
Author

@janesser janesser commented Mar 4, 2019

@pi0 @samtgarson what's the next step here?

@vhf

This comment has been minimized.

Copy link

@vhf vhf commented Mar 11, 2019

I see the point. And auth and axios are probably best examples for such need.

Definitely. The ability to configure auth, axios and apollo at runtime would be immensely helpful to people who wish to build once and deploy many times.

I'd be happy to contribute if the core team agrees on what the right approach should be.

@fvigotti

This comment has been minimized.

Copy link

@fvigotti fvigotti commented Mar 20, 2019

** EDITED to add some elements for clarification of the issue

the problem is that process.env.* gets replaced with "live(build-time)" placeholders during build time,
so runtime env variables that are needed for a 2019-well-designed app to contain things such "axios/apollo links -> which are also needed during those plugins configuration ( in nuxt.config.ts ) " are broken, the solution is https://github.com/samtgarson/nuxt-env and reconfigure those plugins using a plugin in "plugins/..." which use the new injected runtime env from ctx.app.$env there ( the official docs of https://github.com/samtgarson/nuxt-env doens't talk about plugins usage , just store/component )

anyway, I'm quite new with nuxt/vue and having to know so much internals to runtime-configure the application and having to read the (0-comments) source code of https://github.com/samtgarson/nuxt-env to figure out how to configure apollo has been a pain...

my 2 cents are that this is a serious issue, I've lost 3 hours trying to figure out why my local dev env works and my deploy env didn't , the problem was that there was two different graph of injected variables because the build process interpolated them from different build environment,

I think that saying that there is no official way -to use env variables || to inject configuration- at runtime but that https://github.com/samtgarson/nuxt-env that "works" , or to use env variables at build-time (which is an huge anti-pattern in 2019 ) must be written at least here https://nuxtjs.org/api/configuration-env/ with bold characters untill resolved.. and maybe propose this module https://github.com/samtgarson/nuxt-env as a solution ? anyway having someting so hardly testable, so important (that is used to pass auth / tokens / configuration to the application ) on a non-official module (with all the eventual future compatibility problem, version-pairing, .. ) is a sign of project immaturity and should be incorporated in the main app asap.

I want to add that this is a very subtle issue, because the nuxt.config.(ts|js) is run twice, at build time and at runtime, but at build time it will compile apollo/axios and other modules with env variable that are present at build-time , when you run at build time, and try to debug, the nuxt.config.js file is executed with correct env variables, but the configuration for the module that you expect to gets configured during this execution are already configured with hardcoded build-time-value...

@samtgarson

This comment has been minimized.

Copy link

@samtgarson samtgarson commented Mar 21, 2019

@pi0 I'm happy to move the module over to nuxt community if that would help the situation, let me know

@manniL

This comment has been minimized.

Copy link
Member

@manniL manniL commented Mar 21, 2019

@samtgarson Let's discuss that on https://discord.nuxtjs.org/ ☺️

@rmeissn

This comment has been minimized.

Copy link

@rmeissn rmeissn commented Mar 22, 2019

Just to give some idea of a possible solution:
We had the same issue in my old project and we splitted the webpack build step into two steps. One, that builds most parts of the application (e.g. executed by CI/CD) and one smaller step that updates a file with predefined env vars before starting the application. See scripts build:nostart and start in package.json

So the basic steps for a docker deployment (on container execution) are:

  1. An entrypoint script is executed that uses (in our case) envsubst and a template file to create a config file, containing predefined env vars (so they are hardcoded to the resulting json file)
  2. Run a limited webpack build step in order to include this newly created file into the already existing distribution
  3. Execute the distribution (that is now using the env vars used on container startup)

I can perfectly image that these steps may be included into nuxt start command.

@tomsaleeba

This comment has been minimized.

Copy link

@tomsaleeba tomsaleeba commented Mar 25, 2019

I have (had) a need for this too and I use nuxt-env (excellent module) where I can but there are places that nuxt-env can't help like configuring your API URL for the nuxt-proxy module in the nuxt.config.js file.

I run in Docker so I decided to get a bit hacky and just use placeholders during the docker build:

# Dockerfile
...some stuff

RUN \
  export KEYCLOAK_CLIENT_ID='%%KEYCLOAK_CLIENT_ID%%' && \
  export KEYCLOAK_HOST='%%KEYCLOAK_HOST%%' && \
  export KEYCLOAK_REALM='%%KEYCLOAK_REALM%%' && \
  export API_BASE_URL='%%API_BASE_URL%%' && \
  yarn build

... more stuff

Then in the entrypoint.sh for the container, just parse the build JS files:

# entrypoint.sh
find .nuxt/ \
  -type f \
  -name '*.js' \
  -exec sed -i "s+%%KEYCLOAK_CLIENT_ID%%+${KEYCLOAK_CLIENT_ID:?}+g" '{}' \; \
  -exec sed -i "s+%%KEYCLOAK_HOST%%+${KEYCLOAK_HOST:?}+g" '{}' \; \
  -exec sed -i "s+%%KEYCLOAK_REALM%%+${KEYCLOAK_REALM:?}+g" '{}' \; \
  -exec sed -i "s+%%API_BASE_URL%%+${API_BASE_URL:?}+g" '{}' \;

exec yarn start

It's not glamorous but it gets the job done. It works for local dev (yarn dev) too because you can pass the env var directly. The downside is that you have to update the docker files when you need a new var but I can live with that. You could always get fancy and scan the env in the entrypoint for a certain prefix and then update all the matching env vars, but that's gold plating for me right now.

@stale

This comment has been minimized.

Copy link

@stale stale bot commented Apr 15, 2019

Thanks for your contribution to Nuxt.js!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If you would like this issue to remain open:

  1. Verify that you can still reproduce the issue in the latest version of nuxt-edge
  2. Comment the steps to reproduce it

Issues that are labeled as 🕐Pending will not be automatically marked as stale.

@stale stale bot added the stale label Apr 15, 2019
@vhf

This comment has been minimized.

Copy link

@vhf vhf commented Apr 15, 2019

This is still an important issue for those who'd like to build easily deployable products with Nuxt. It would be good if stalebot didn't close it IMO.

@stale stale bot removed the stale label Apr 15, 2019
@nachogarcia

This comment has been minimized.

Copy link

@nachogarcia nachogarcia commented Nov 14, 2019

IMO docker images should be stateless, so I push to the image the node modules, nuxt config and dist folder. This achieves a fast startup. Not sure if it would work for me.

@cardaddy

This comment has been minimized.

Copy link

@cardaddy cardaddy commented Nov 15, 2019

I'm trying to build my application with some args from my docker build and I'm not seeing them get populated within my auth module. However the env variable appears to work fine outside of nuxt.config.js. If I use dotenv, auth module is capable of reading the values, however I can't seem to overwrite them with docker. What am I doing wrong?

strategies: {
  company: {
    _scheme: 'oauth2',
    authorization_endpoint: process.env.BASE_URL + '/auth/oauth/authorize',
    access_token_endpoint: process.env.BASE_URL + '/auth/oauth/token',
    userinfo_endpoint: process.env.BASE_URL + '/auth/users/me',
@samtgarson

This comment has been minimized.

Copy link

@samtgarson samtgarson commented Nov 19, 2019

@cardaddy I think you need to open that issue with the auth module directly, as I believe it's the module itself that is baking the config into the build output (I think it's in this line).

You can try using nuxt-oauth if you're just after a basic OAuth integration, we use that in production and it works with docker.

@ZinkNotTheMetal

This comment has been minimized.

Copy link

@ZinkNotTheMetal ZinkNotTheMetal commented Nov 20, 2019

app.$axios.defaults.baseUrl = app.$env.BASE_URL

Do you have an example, I just started with NUXT and I'm confused where to set this

@cardaddy

This comment has been minimized.

Copy link

@cardaddy cardaddy commented Nov 20, 2019

@ZinkNotTheMetal I'm setting the value in nuxt.config.js

axios: {
baseURL: process.env.BASE_URL,
credentials: true
},

@ZinkNotTheMetal

This comment has been minimized.

Copy link

@ZinkNotTheMetal ZinkNotTheMetal commented Nov 20, 2019

@cardaddy
I did that, but these are still build time variables right? I'm trying to pass in an OpenShift (docker) variable into the nuxt.config.js and I feel like I've spent too long trying to do this....

@danielroe

This comment has been minimized.

Copy link
Contributor

@danielroe danielroe commented Nov 20, 2019

@ZinkNotTheMetal You'll want to do it in a plugin.

@cardaddy

This comment has been minimized.

Copy link

@cardaddy cardaddy commented Nov 20, 2019

Yes, these are not runtime variables and must be set at build time. Perhaps one of the nuxt guys will be able to shed some light on it, but I struggled to set different base_urls passing in environment variables and still having a default for local dev. I ended up setting up nuxt dotenv and ultimately setting my .env file during my docker build process. I think this is an area that needs a lot of improvement.

@ZinkNotTheMetal

This comment has been minimized.

Copy link

@ZinkNotTheMetal ZinkNotTheMetal commented Nov 20, 2019

Yes, I have spent the better part of an afternoon trying everything under the sun to get runtime variables into nuxt.
I don't see how this doesn't break the build once - deploy many times paradigm that javascript seems to strive for. Hopefully this feature will come soon. Thanks for the post and the help

@cardaddy

This comment has been minimized.

Copy link

@cardaddy cardaddy commented Nov 20, 2019

Yes it does seem to break that paradigm and I find it to be quite frustrating, but hopefully in time it will be resolved.

If you end up using the nuxt auth module, you'll find it wont be able to read the standard nuxt environment variables in nuxt.config.js auth strategies, you'll need dotenv to get it to work. I'm too looking for a better solution.

@samtgarson

This comment has been minimized.

Copy link

@samtgarson samtgarson commented Nov 20, 2019

@ZinkNotTheMetal A plugin works for setting axios defaults using environment variables from nuxt-env, although we've had other issues with that module and have switched back to vanilla axios.

It would be great to hear from nuxt team on this regarding strategy, but the issue is with axios and Auth module among others.

At Soho House we use nuxt in prod with docker images in kubernetes, and use regular axios (without the nuxt module), nuxt-oauth and other modules along with nuxt-env to handle environment variables just fine—its only an issue with modules that template options into build artefacts.

(PS I'm sure those modules would accept PRs to fix this 🙃)

@cardaddy

This comment has been minimized.

Copy link

@cardaddy cardaddy commented Nov 20, 2019

@samtgarson You should create a blog illustrating your build and how you got everything to work. Getting all these modules to work together has been nightmare.

@superbiche

This comment has been minimized.

Copy link

@superbiche superbiche commented Nov 26, 2019

I'm also deploying on Kubernetes, using GitLab's auto review feature.
After spending the afternoon trying to find a good workaround, I ended up re-building the app before running yarn start. So I'm bundling the app in the image during the build, and redo the bundle before it starts.
Not great for auto scaling or reducing my cluster's production worker load.

@jslegers

This comment has been minimized.

Copy link

@jslegers jslegers commented Jan 31, 2020

I'm also experiencing the same issue when trying to configure the Auth module to use Auth0 as an authentication service.

The Nuxt build is supposed to be the same for our dev environment and our staging environment, but both environments use a different database and different auth0 endpoints.

I can use env variables to set the auth0 endpoints in nuxt.config :

  /**
   * Auth module configuration
   */
  auth: {
    redirect: {
      login: '/login',
      callback: '/callback',
      home: '/',
    },
    strategies: {
      auth0:{
        authorization_endpoint: `https://${env.AUTH0_DOMAIN}/authorize`,
        userinfo_endpoint: `https://${env.AUTH0_DOMAIN}/userinfo`,
      },
    },
    plugins: [
      { src: '~/plugins/auth.js' },
    ],
  },

However, this causes the endpoints of the dev environment to be hardcoded into the Nuxt build... which means the wrong endpoints would be used in the staging environment.

Embedding env variables in a Nuxt build may make sense in situations where every environment has its own build, but the moment you want to use the same build for different environments, you're in trouble. And using different builds for dev and staging kind of defeats the purpose of having a staging environment in the first place...

@morficus

This comment has been minimized.

Copy link

@morficus morficus commented Feb 1, 2020

@jslegers for you case specifically, you could setup a proxy to solve this.
that way your auth0 endpoints are just /auth/authorize and /auth/userinfo (no domain name attached) and the proxy config would then use the AUTH0_DOMAIN env var.

Your nuxt.config.js file would look like this

strategies: {
  auth0:{
    authorization_endpoint: '/auth/authorize',
    userinfo_endpoint: '/auth/userinfo',
  },
},

proxy: {
  '/auth': {
    target: env.AUTH0_DOMAIN,
    pathRewrite: {
      '^/auth': '/'
    }
  }
@albanm

This comment has been minimized.

Copy link

@albanm albanm commented Feb 4, 2020

FYI I worked on a small module to solve difficulties encountered around this subject.

https://github.com/koumoul-dev/nuxt-config-inject

It is a brutal solution based on search and replace in the built files. It seems to be working quite well for our needs right now. Config elements that are interpreted in an advanced way at build times will not work. But env vars, metas, i18n messages, webpack public path, router base, etc all seem to work.

Not satisfactory in many ways, but hey, right now we have containers starting in 1 or 2 seconds and fetching config directly from multiple environments.

@jslegers

This comment has been minimized.

Copy link

@jslegers jslegers commented Feb 4, 2020

@jslegers for you case specifically, you could setup a proxy to solve this.
that way your auth0 endpoints are just /auth/authorize and /auth/userinfo (no domain name attached) and the proxy config would then use the AUTH0_DOMAIN env var.

And I suppose the idea is that the proxy would forward to the correct endpoint based on the referrer path?

I guess this could work as a workaround, but I'd rather avoid this extra forwarding. Also, there are other parameters we'd like to keep different between environments.

In fact, I just learnt that we're even using the same build for production... which only further complicates this matter.

@morficus

This comment has been minimized.

Copy link

@morficus morficus commented Feb 5, 2020

And I suppose the idea is that the proxy would forward to the correct endpoint based on the referrer path?

@jslegers I'm not sure what you are calling the "referrer path", but take a look at the proxy module documentation and the config I added should make more sense. I don't mind helping if you have more questions.

@kensixx

This comment has been minimized.

Copy link

@kensixx kensixx commented Feb 18, 2020

I couldnt agree more, currently the env variables dont really cut it, espically when using docker images etc.

The reality of using nuxt-axios in a docker image, currently using nuxt-env

export default function({ $axios, app }) {
  if (process.server) {
    $axios.defaults.baseURL = `http://localhost:${app.$env.PORT || '5000'}`
  } else {
    $axios.defaults.baseURL = app.$env.EP_BASE_URL || `http://localhost:${app.$env.PORT || '5000'}`
  }
}

I'm getting a headache for about 2 days over this problem with Nuxt on my runtime env variables using k8s and Docker..

Hi @blowsie, this really helped editing the nuxt-axios's plugins/axios.js using nuxt-env. Thank you so much..

I never knew that the $axios.defaults property existed.. It is not visible anywhere in the Nuxt Axios docs..

Hope the Nuxt core team resolves this one out by supporting runtime env variables especially when using Kubenetes, CI/CD, Docker, etc.

@kensixx

This comment has been minimized.

Copy link

@kensixx kensixx commented Feb 18, 2020

app.$axios.defaults.baseUrl = app.$env.BASE_URL

Do you have an example, I just started with NUXT and I'm confused where to set this

this is the whole code of my plugins/axios.js, hope it helps (if you still need it)

export default function({ $axios, app }) {
  // set Nuxt Axios' global configuration to use this runtime env variable to make requests
  // Resource: https://github.com/nuxt/nuxt.js/issues/5100#issuecomment-587337547
  // Resource: https://github.com/samtgarson/nuxt-env
  $axios.defaults.baseURL = app.$env.API_URL

  $axios.onRequest((config) => {
    // Adds this header to all requests
    config.headers['Access-Control-Allow-Origin'] = config.baseURL
    config.timeout = 1800000
  })
}
@hynding

This comment has been minimized.

Copy link

@hynding hynding commented Mar 6, 2020

Can someone identify where in webpack the process.env variables are being replaced during the build process? I'm assuming the "build" nuxt.config option has already been explored for preventing this functionality (and failed).

@blowsie

This comment has been minimized.

Copy link

@blowsie blowsie commented Mar 9, 2020

@hynding , its simply when the server file is generated its taking the variables from the node runtime

@rick-stevens

This comment has been minimized.

Copy link

@rick-stevens rick-stevens commented Mar 18, 2020

Our company uses multi-stage deployment as well (k8s) where the build step has no access to the runtime environment variables at all. We're often using env in server middleware and nuxt.config.js where nuxt-env doesn't reach. Been eagerly awaiting support for over a year. Please help!

@samtgarson

This comment has been minimized.

Copy link

@samtgarson samtgarson commented Mar 18, 2020

@rick-stevens surely in nuxt config and server middleware you can just use process.env? These files are only run server side AFAIK

@samtgarson

This comment has been minimized.

Copy link

@samtgarson samtgarson commented Mar 18, 2020

I misread your bit about the multistage build 🤦‍♂️😅

@chanon

This comment has been minimized.

Copy link

@chanon chanon commented Mar 20, 2020

I just wasted about 4 hours trying to get my Nuxt app to run in my Kubernetes cluster because of this. It is 2020 and 12 factors applications are supposed to be the best practice.

Whatever the solution, please make a clear distinction between

  • environment on server when app was built (eg. when use nuxt build or nuxt generate)
  • environment on server when app was run (eg. when use nuxt start)

Maybe make it app.$buildEnv and app.$runtimeEnv

Configuration could be similar to nuxt-env, but separate them so you can set which env vars you want from runtime and from buildtime. Separating them like this will make it clear where the env is coming from.

Make sure the envs are available in app context in plugins, components when rendered client side or server side rendered, in SSR and SPA mode ... everywhere and make them consistent.

Also make it consistent inside nuxt.config.js if possible or maybe document it so when process.env is called inside nuxt.config.js it is clear if it is coming from build time or run time.

@DreaMinder

This comment has been minimized.

Copy link

@DreaMinder DreaMinder commented Mar 27, 2020

I've created a module based on this implementation #5100 (comment)

https://github.com/DreaMinder/nuxt-env-injector
⚠️ Don't use It in production yet. ⚠️

I would appreciate any kind of feedback. In case it is not what you expect as a solution to this issue.

@mefcorvi

This comment has been minimized.

Copy link

@mefcorvi mefcorvi commented Mar 30, 2020

@DreaMinder You may want to take a look at https://github.com/koumoul-dev/nuxt-config-inject, it handles several edge cases that aren't supported in your solution. For example, in some cases it's important whether value starts with http://or not, you can't use just %%INJECTED_myvar%% there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.