src/server/utils.ts ```ts import 'server-only' export function getEnv(): Env { const grc = getReq

src/server/utils.ts

import 'server-only'

export function getEnv(): Env {
  const grc = getRequestContext().env as unknown as Env;

  if (grc.SECRET_KEY != null) {
    return grc;
  } else if (process.env.SECRET_KEY != null) {
    return process.env as unknown as Env;
  } else {
    throw new Error("Env variables are not defined");
  }
}

import 'server-only'

export function getEnv(): Env {
  const grc = getRequestContext().env as unknown as Env;

  if (grc.SECRET_KEY != null) {
    return grc;
  } else if (process.env.SECRET_KEY != null) {
    return process.env as unknown as Env;
  } else {
    throw new Error("Env variables are not defined");
  }
}

import 'server-only'

export function getEnv(): Env {
  const grc = getRequestContext().env as unknown as Env;

  if (grc.SECRET_KEY != null) {
    return grc;
  } else if (process.env.SECRET_KEY != null) {
    return process.env as unknown as Env;
  } else {
    throw new Error("Env variables are not defined");
  }
}

import 'server-only'

export function getEnv(): Env {
  const grc = getRequestContext().env as unknown as Env;

  if (grc.SECRET_KEY != null) {
    return grc;
  } else if (process.env.SECRET_KEY != null) {
    return process.env as unknown as Env;
  } else {
    throw new Error("Env variables are not defined");
  }
}

is this fine?

getRequestContext()

getRequestContext()

and

process.env

process.env

is still very confusing. sometimes they work in local, sometimes they dont work in prod, so i made this utility function

bunOP•4/8/24, 6:02 PM

right now process.env works on local, but getRequestContext doesn't, when it always did in the past, very weird

Bbun src/server/utils.ts ```ts import 'server-only' export function getEnv(): Env { ...

Dario•4/8/24, 8:14 PM

both

getRequestContext()

getRequestContext()

and

process.env

process.env

should with

next dev

next dev

wrangler pages dev

wrangler pages dev

and production
(and you should ideally always use

getRequestContext()

getRequestContext()

)

If either doesn't work in some scenario, could you please open an issue (ideally with a minimal reproduction): https://github.com/cloudflare/next-on-pages/issues/new?assignees=&labels=bug&projects=&template=bug-report.yml&title=%5B%F0%9F%90%9B+Bug%5D%3A+

so that I can take a look and address the bug?

(most definitely you should not have to define utility functions like the one you shared!

)

bunOP•4/8/24, 8:44 PM

ill make a repro once i can

bunOP•4/8/24, 8:45 PM

but the idea is

server component -> server action -> server utility - (getRequestContext() doesn't work here)

Dario•4/8/24, 8:47 PM

mh... odd

Dario•4/8/24, 8:47 PM

thanks, I'll give it a try

(but yeah a repro would definitely speed things up

)

DDario thanks, I'll give it a try 🙂 (but yeah a repro would definitely speed things up...

bunOP•4/8/24, 9:04 PM

https://github.com/sunneydev/next-on-pages-env-bug-repro

GitHub

GitHub - sunneydev/next-on-pages-env-bug-repro

Contribute to sunneydev/next-on-pages-env-bug-repro development by creating an account on GitHub.

bunOP•4/8/24, 9:04 PM

here

bunOP•4/8/24, 9:04 PM

seems like its only for environment variables

bunOP•4/8/24, 9:04 PM

that are defined in

.env

.env

bunOP•4/8/24, 9:04 PM

or maybe for other ones as well, not sure exactly

bunOP•4/8/24, 9:05 PM

ah the action doesn't work as well, no need 3rd (utility) layer at all

bunOP•4/8/24, 9:06 PM

so like its for

.env

.env

files that are locally defined i guess,

bunOP•4/8/24, 9:06 PM

nextjs accounts for them in process.env but not

getRequestContext()

getRequestContext()

i guess

Dario•4/8/24, 9:28 PM

Thanks a lot @bun

Dario•4/8/24, 9:29 PM

oh....

bunOP•4/8/24, 9:29 PM

tldr bindings work, env variables defined in

.env

.env

dont. with

getRequestContext()

getRequestContext()

locally

Dario•4/8/24, 9:29 PM

you're not using .dev.vars.dev.vars are you...?

bunOP•4/8/24, 9:30 PM

nope, regular

.env

.env

bunOP•4/8/24, 9:30 PM

.dev.vars.dev.vars woudl work?

Bbun nope, regular `.env`

Dario•4/8/24, 9:31 PM

yeah that's not going to work

(I did try to convince the team to fix this but it seems like people are happy with the current way of not reading the

.env

.env

file

)

Bbun `.dev.vars` woudl work?

Dario•4/8/24, 9:31 PM

yes, you should have a .dev.vars.dev.vars file that contains the exact same content as your

.env

.env

file

Dario•4/8/24, 9:32 PM

https://developers.cloudflare.com/workers/configuration/secrets/#secrets-in-development

Cloudflare Docs

Secrets · Cloudflare Workers docs

Store sensitive information, like API keys and auth tokens, in your Worker.

bunOP•4/8/24, 9:32 PM

thats fine im ok with that, but its crucial that these edge cases should be documented in a single place somwhere as a lot of nextjs devs will run into these kind of issues

Dario•4/8/24, 9:33 PM

yes.... that's a totally valid point....

bunOP•4/8/24, 9:34 PM

and i dont think a lot of people will play close attention to github docs as not a lot of people use github for docs, maybe have a separate website for this? idk

Dario•4/8/24, 9:34 PM

https://github.com/cloudflare/next-on-pages/issues/604

GitHub

Documentation: Environment variables · Issue #604 · cloudflare/next...

It would be very convenient if https://developers.cloudflare.com/pages/framework-guides/deploy-a-nextjs-site/ also mentioned that for Next.js (and its command dev) you can use the .env file as usua...