manterfield Posts - Answer Overflow

manterfield

•Created by manterfield on 12/5/2024 in #pages-help

How are we supposed to use env vars outside of request contexts - e.g. When setting a config value?

I've found myself stumped on the stupidest thing. I'm using a third party integration with Astro, it takes config within the astro.config.mjs file like so:

kinde({
    clientId: process.env.KINDE_MANAGEMENT_CLIENT_ID,
    clientSecret: process.env.KINDE_MANAGEMENT_CLIENT_SECRET,
    domain: process.env.KINDE_DOMAIN,
    callbackUri: "http://localhost:4321/api/kinde/callback",
    signedInUri: "http://localhost:4321",
    signedOutUri: "http://localhost:4321",
    sessionMaxAge: 3600,
}),

kinde({
    clientId: process.env.KINDE_MANAGEMENT_CLIENT_ID,
    clientSecret: process.env.KINDE_MANAGEMENT_CLIENT_SECRET,
    domain: process.env.KINDE_DOMAIN,
    callbackUri: "http://localhost:4321/api/kinde/callback",
    signedInUri: "http://localhost:4321",
    signedOutUri: "http://localhost:4321",
    sessionMaxAge: 3600,
}),

Now obviously process.env isn't going to work, so I figured I'd check the equivalent. I've used ctx.env within requests for other things, but that isn't going to work here. aaaand... I found nothing. As far as I can tell there's no way for me to pass these relatively static env vars into a config. I've found people mentioning build time/vs runtime env vars and how perhaps they would help (having to build and deploy to change these values would be perfectly acceptable) - but I can't see docs on this beyond the fact that env vars exist at build time (but nothing on how I could make use of them, since there's no request context). What's the expected/recommended solution here? --- More soapboxy thoughts: This 'env vars only available in a request context' has caused a little friction for me in a few places. Elsewhere that friction has been solvable, but here I'm stumped. Still, I'd prefer to not have to work out solutions to this anywhere ever. I just want some per env config! I think I kinda get why it has been done this way - I could see global scope caching between requests being tricky when that 'env' includes things like D1 bindings, but it feels like static string env vars accepting the limitations imposed by very different concerns is heavy handed. Hopefully I'm just missing the obvious way to make this a non-issue.

2 replies

Gaming

Programming