it smells wrong

Weird. The only thing I can think of that I'm doing different than your example is that I'm using .env.local file

.env.local should be the same as well

can you give me a minimal reproduction repository

Uh... I'll try to replicate it and pass you the repo, but couple of quick questions.
- When I log the process.env, all I see is { NEXT_RUNTIME: "edge" } and no other environment variables. Does NEXT_RUNTIME ring any bells?
- What version of NextJS are you using?

Here's how my middleware.ts file looks like

import { NextRequest } from 'next/server';

import MediaReverseProxy from './features/reverse-proxies/media-urls';

export async function middleware( request: NextRequest ) {
  console.log(process.env);
  const { pathname } = request.nextUrl;
  if ( getMediaUrlRegex().test( pathname ) ) {
    const reverseProxy = new MediaReverseProxy( request );
    return reverseProxy.respond();
  }
}

I'm reading online that Edge Runtime does not have access to usual .env file as those .env are only used during build time..

Unless this has been changed lately you have to set env variable at build time in middlewares
but normally the .env.local way should work in this case

ah yea

you cannot log process.env this way

it's a value injected at build time, which is similar to how NEXT_PUBLIC variables work

only "process.env.FOOBAR" will work because it actually gets replaced inline during build

Oh... that explains a lot of things! Okay, so the problem is way complicated now with that revelation, lol.

The situation I'm in, I have variables are suffixed with locale. Like FOOBAR_ES, FOOBAR_IT, etc. When I try to print it the way you recommend, it works fine. I was trying to access them with little bit of dynamism where I detect the locale ES or IT or FR, etc. And then read the corresponding FOOBAR variable.

Now since that's out of the equation, do I have an alternative option to achieve what I want or I should resort to a JSON File instead of env File?

If I understand correctly, that looks like pre-compilation search and replace, no?

that indeed exactly what happens during compilation, this is done in Next.js built-in webpack config (or their new turbopack thingy)

What are you trying to achieve? I would get the local from the user and embed a config that contains info for all locales, without relying on runtime env var

here is our middleware that handles i18n at Devographics if that's of any help: https://github.com/Devographics/Monorepo/blob/main/surveyform/src/middleware.ts

There are plenty other alternatives given that you are not really limited by bundle size for middlewares

so you can generate automatically a string that covers all your locales and shove it in your middleware

like "const localeIt = process.env.LOCALE_IT; const localeFr = process.env.LOCALE_FR" <- write a script that just generate that for you and copy paste into your middleware, and call it a day

but this is not extra relevant as you cannot alter the value at runtime, so this kinda defeat the purpose of having env variables in the first place