Next.js: Ability to pass custom config information from next.config.js to the browser

[alexindigo]

We need ability to pass custom config information at runtime to the browser, in the same fashion next.js passes assetPrefix from next.config.js.

• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Ability to add custom information (like graphql endpoint) to next.config.js, something like:

module.exports = {
  assetPrefix: process.env.CDN_PREFIX,
  config: {
    graphql: {
      uri: process.env.GRAPHQL_ENDPOINT
    },
    myCustomThing: '2345678',
    myCustomList: [ 'a', 'b', 'c' ]
  }
};

and a way to consume it in the app running in the browser, like:

const { config } = __NEXT_DATA__

Current Behavior

Nothing happens

Context

We're building immutable images that later deployed to the different environments, so there is no way for us to mutate the code and bake in API endpoints, we need this feature to provide API endpoints via environment variables at runtime.

Thank you.

[alexindigo]

This issue expresses similar sentiment :) https://github.com/zeit/next.js/issues/3160

[tz5514]

next.config.js is a config file that only for next.js core feature.
I think you can just use babel-plugin-transform-define to do this in next.js.

[alexindigo]

@tz5514 Thanks for the suggestion. The this is we run babel at the build step, then we create (immutable) artifact and run that in different environments. So not sure how it would help this use case.

[timneutkens]

@alexindigo Have you seen https://github.com/zeit/next.js/tree/canary/examples/with-universal-configuration-runtime

This is how we do it for zeit.co

[alexindigo]

@timneutkens Thanks. This is the pretty much workaround I created for our app. But it feels like a hack rather than stable solution. And during last discussion with @rauchg it was the decision to go for more centralized way of passing env vars.

[rauchg]

The only concern I have is that it's not clear based on the next.config.js config field that that config will be exposed in _runtime_, potentially creating serious security issues. People could assume that the config is for the server, for example.

Maybe we need to name it differently?

[Vadorequest]

clientConfig instead of config would be a transparent naming and avoid such security issues

[timneutkens]

@vadorequest we’ve settled on making config private and having a key called public to mark the public variables. Similar to how meteor does it. This gives maximum flexibility. See above PR that implements next/config

[Vadorequest]

@timneutkens Works too! :)