-
Notifications
You must be signed in to change notification settings - Fork 26.4k
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
Confused about usage of process.env #22266
Comments
Okay, after some more tests it seems to me that the following is the case: IF a NEXT_PUBLIC_ env variable is present at build time, it will be replaced in the code. But in NODE_ENV=production NEXT_PUBLIC_Vars are not available client side (can see the runtime value in the serverside rendered page, but client rerenders it as undefined and thus empty) |
Thanks for posting this. I think I've seen the same thing, but from a different angle. I'm using Typescript in one of my projects and when I went to replace a couple things in my GraphQL client-side config with process.env.NEXT_PUBLIC_foo, it was generating an compiler error/warning because it was showing the type of process.env.NEXT_PUBLIC_foo as 'string | undefined'. Having read this, I'm wondering if .... |
I was frustrated about this and made a repo that clarifies the differences: Also worth noting that I made a small issue of this, as the reason the above i confusing is because the word |
There is something still unclear to me: what about injecting global variables in the frontend code during build. For instance, if you want to access the current application version from package.json in the frontend, you have two ways:
// Define an environment variable so source code can check whether or not
// it's running on the server so we can correctly initialize Sentry
config.plugins.push(
new options.webpack.DefinePlugin({
'process.env.NEXT_IS_SERVER': JSON.stringify(
options.isServer.toString()
),
})
) This code is taken from Sentry official example, that uses a combination of those patterns: https://github.com/vercel/next.js/blob/canary/examples/with-sentry/next.config.js |
Would be nice to support this while not completely opting out of static optimization to set some variables once during server start |
In the meantime I've written an article that details more precisely the various ways we can load configuration, from env or computed dynamically: https://blog.vulcanjs.org/how-to-set-configuration-variables-in-next-js-a81505e43dad |
Thats a great explanation Eric! Thanks a lot for the article. Cheers |
just wanted to share my experience with this Runtime configuration. here is my case: our app is integrated with another our "3rd-party" app. each app has its own set of envs which are used for deployments. our intention was to build our app once and it should consume right URL to specific env of 3rd-party app during runtime. in another words
and it does not work, because all of probably runtime should be renamed to boot-time or startup-time (if it would work that way) |
I've also stumbled over that issue: I tried the all options the docs are saying here, which was very frustraiting:
Last but not least I got it working, I suggest updating the docs, or make it more clear what's the best approach to deploy and use in "2021". What definitely didn't work for me was the I set
my module.exports ={
// your config for other plugins or the general next.js here...
// Will only be available on the server side
serverRuntimeConfig: {
demo_api_url: process.env.API_URL,
},
// Will be available on both server and client
publicRuntimeConfig: {
demo_public_api_url: process.env.NEXT_PUBLIC_API_URL,
},
}; Then in my ApiClass: import getConfig from 'next/config'
const { serverRuntimeConfig, publicRuntimeConfig } = getConfig()
const PublicApiUrl = process.env.NEXT_PUBLIC_API_URL;
const ApiUrl = process.env.API_URL;
const shopApi = {
getProducts: (options: GetOptions = {}): Promise<Product[]> => {
console.log("PublicApiUrl alias:", PublicApiUrl);
console.log("API_URL:", process.env.API_URL);
console.log("NEXT_PUBLIC_API_URL:", process.env.NEXT_PUBLIC_API_URL);
console.log("publicRuntimeConfig:", publicRuntimeConfig);
console.log("serverRuntimeConfig:", serverRuntimeConfig);
console.log("demo_public_api_url:", publicRuntimeConfig.demo_public_api_url);
console.log("demo_api_url:", serverRuntimeConfig.demo_api_url);
return fetch(`${PublicApiUrl}/products/index.json`).then(
(response) => response.json()
); This is the console output SERVERSIDE:
|
@exocode The |
Only client-side values are inlined as documented here: |
Edit: Sorry, misunderstood your answer. But that's the thing. According to the article they are inlined in the code that is send to the browser. Meaning that I can use runtime env vars on the system it is running on. But that doesn't work as mentioned above. The values are not present client-side |
@damianon when static optimization occurs things are bundled during buildtime. Opt-out of using As a sidenote this took me forever to figure out, the next documentation is not clear at all on how to actually get this to work. |
This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
What version of Next.js are you using?
10.0.5
What version of Node.js are you using?
14
What browser are you using?
Firefox
What operating system are you using?
Windows
How are you deploying your application?
cross-env NODE_ENV=production node server.js
Describe the Bug
I'm very confused about the use of process.env. Variables.
(Here in the docs)[https://nextjs.org/docs/basic-features/environment-variables] it says 'In order to keep server-only secrets safe, Next.js replaces process.env.* with the correct values at build time.' However looking into my docker container (or the locally compiled code) in the .next folder i can clearly still see
process.env.VAR_NAME
in all the places, and runtime environment variables are used. (all our pages are serverside rendered, not statically)While this is mostly what I want, there are two cases where i want build time fixed variables, so looking into it, it's not very clear how this can be achieved.
Also under the (runtime variables docs)[https://nextjs.org/docs/api-reference/next.config.js/runtime-configuration] it suggests using serverRuntimeConfig/publicRuntimeConfig together with
getInitialProps
which however is aparently deprecated in favor ofgetServersideProps
. Also when I tried using this mapping in the next.config.js using the next config on a page always returned both of these as empty arrays (public and server).So I have as of now no clue at all on how to achieve both runtime and build time environment variables. So far in my project process.env. seems to be runtime and serverRuntimeConfig didn't work at all.
If process.env. is in fact runtime, that's fine, but then the docs are wrong in stating it's build time.
server.js is just a express wrapper for next:
Expected Behavior
A clear way on how to use environment variables defined at build time and at runtime. (e.g. i want the version to be fixed at build time, but some connection strings at runtime)
To Reproduce
Use process.env. variables somewhere in pages or components.
run
next build
inspect .next generated code and still find process.env (even if the docs state the opposite)
The text was updated successfully, but these errors were encountered: