`process.env` is prefered over `import.meta.env`

Environment

node 20.11
std-env 3.7

Reproduction

not really relevant

Describe the bug

So I'm not sure if I'd call this a bug per-se, maybe more of an observation to open up a discussion how we could solve this.

Astro is a bit (if you ask me) dumb in the way that they have a process.env on the server but they don't populate it with stuff from your env file. That stuff goes on import.meta.env. This means that the following logs undefined:

import { process } from "std-env";
console.log(process.env.SOME_ENV_FROM_ENVFILE);

This is cause (like I said), process does exists, so std-env chooses it as the env object: https://github.com/unjs/std-env/blob/7528b1324ab48dea93c0739b0b046e0d5607fcf5/src/env.ts#L5-L10

Any ideas how to solve this in a nice way? I think this is just a stupid behavior from Astro but any workaround we can do to support this would be great. We recently moved to std-env in uploadthing to have a single source of truth for accessing environment variables but then I stumbled on this edge-case...

Additional context

No response

Logs

process.env {
  MANPATH: '/opt/homebrew/share/man::',
  COREPACK_ROOT: '/Users/julius/Library/Application Support/fnm/node-versions/v20.11.0/installation/lib/node_modules/corepack',
  BUNCH_OF_STUFF: "THAT I REMOVED",
  NODE_ENV: 'development'
}
import.meta.env {
  BASE_URL: '/',
  MODE: 'development',
  DEV: true,
  PROD: false,
  SSR: true,
  SITE: undefined,
  ASSETS_PREFIX: undefined,
  UPLOADTHING_SECRET: 'sk_live_xxxxxx' // <-- this is coming from .env.local
}

Start with src/env.ts at lines 5-10, then reproduce the difference between process.env and import.meta.env in the reported Astro setup. Review the five-comment discussion for the intended precedence or fallback behavior, and consider the regression coverage needed to show that environment values remain correct across supported runtimes.