Introduce env to next.config.js for build-time configuration

[dav-is]

Build time configuration

The way build-time configuration works is by inlining the provided values into the Javascript bundle.

You can add the env key in next.config.js:

// next.config.js
module.exports = {
 env: {
   customKey: 'value'
 }
}

This will allow you to use process.env.customKey in your code. For example:

// pages/index.js
export default function Index() {
 return <h1>The value of customEnv is: {process.env.customEnv}</h1>
}

Also adds an error when publicRuntimeConfig / serverRuntimeConfig is used in combination with target: 'serverless'

[developit]

LGTM - question though: I know convention indicates defines should be process.env.*, but in this case, is there a way to skip prefixing for a field? I've seen a common technique be to define something like an SSR global (if (SSR) {}).

[dav-is]

@developit

How about if the key is prefixed with _ (like _SRR)?

https://github.com/zeit/next.js/pull/6212/files#diff-5bfca4ba8d55b02e7cf3885c1f5439d8R1561

[timneutkens]

@developit I don't think we should introduce the option for users to add global variables like that, especially with type checking / linting that can become an issue. Next.js provides process.browser automatically (but undocumented), mostly because we saw a lot of users do this because webpack provides it automatically, except the way that is handled in webpack it mean that extra code is shipped instead of replacing at build time.

[timneutkens]

Could you add a test for this in test/integration/config

[marcinczenko]

I have some observations about this approach.

1. There is a duplication between env in now.json and env in next.config.js. Understanding the difference between the two is tricky for me and will be even more tricky to new users.

2. As indicated, the env setting in next.config.js is only build configuration, which is basically the same as using env or build.env in now.json, which currently already makes all environment variables available on the server side, which means you can tunnel it to the client side using getInitialProps.

3. env in now.json works with secretes. env in next.config.js does not - at least not directly. I tried to make it work by first referring to the secret in env in now.json and then referring to process.env in env section in next.config.js. Something like this:
   
   in now.json:

   "env": {
     "MY_SECRET": "@my-secret"
   }
   

   in next.config.js:

   env: {
     mySecret: process.env.MY_SECRET
   }
   

   But this only works when running locally (e.g. MY_SECRET="my secret" yarn dev), but does not seem to work on the server. (to make it work on the server it turns out that we need to use build.env in now.json - thanks @revskill10 for pointing it out).

So, what is then really advantage of having env in next.config.js? It does not seem to support secrets, so its use is really limited. Wouldn't it make sense to forward process.env that comes after evaluating from now.json? The next builder should have access to it, but it looks that environment is not forwarded. Then we would not need env param in next.config.js, which to me just adds to confusion.

[revskill10]

@marcinczenko In the last point, i think it should just work with build.env , not env.
The env in next.config.js works with only build-time environment variables, not runtime like the env in now.json, thats why you couldn't make it work.

Having the env in next.config.js is a convenient way to inject build time env variables, instead of installing a bunch of 3rd party dependencies like babel-env plugin, or hacking on webpack config, so i think it's nessessary.

[marcinczenko]

Thanks @revskill10. I will check build.env option. I must be missing a lot form how internals work, so I would agree with your argument about necessity of having env option in next.config.js in order to avoid using workarounds based on babel-transform-inline-environment-variables. It feels dirty, but if there is no better way or this is temporary quick win, it should be fine.

[marcinczenko]

@revskill10 confirmed. build.env works.

[cmcaboy]

I may be missing something here, but it appears that the config key reference is only for build time env variables? Are there no solutions for run time variables with serverless?

[cmcaboy]

I was able to fix this by tunneling the process.env. down through getInitialProps to the client.