-
Couldn't load subscription status.
- Fork 32
Description
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:
Lines 5 to 10 in 7528b13
| const _getEnv = (useShim?: boolean) => | |
| globalThis.process?.env || | |
| import.meta.env || | |
| globalThis.Deno?.env.toObject() || | |
| globalThis.__env__ || | |
| (useShim ? _envShim : globalThis); |
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
}