This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
env variables aren't populated even though process.env exists #853
Comments
If the library requires The blessed way Astro supports env vars is through I don't think this is a bug in Astro. Maybe there's a confusion with how env vars work here that we could improve on though. |
Yes, that's what we do. We use For "normal" Vite frameworks, this works since they only have https://github.com/unjs/std-env/blob/main/src/env.ts#L6-L7 We'd ultimately like to offer Astro user a good experience with 0 config (just have the variable set in your .env) but that's just not possible without heavy special treatments to resolve the variable |
We can definitely look into a feature request to populate |
wondering why you belive this? |
Some ecosystem examples that fill
Vite, uses
I think for sake of ecosystem compatibility for Astro, it really makes sense that if |
The environment story definitely needs to be revisited soon. However, should automatically adding things to process.env be the ideal solution? |
Yes - it's literally the most used in the industry... |
For example,
I don't think every metaframework needs to make |
No, Vite and also runtimes like jiti we already adopted it to help migration from Node.js Yes, I suppose there is no need from Node.js to endorse a new convention of
Again, a love Vite but I don't belive Vite alone can set a baseline like this.
Yes and that's probably a limitation for Vite and is solvable. Nuxt, uses vite and supports it. Your point is that dotenv does not works in Vite without configuration and I agree, yes today it won't.
Maybe, i am also not always fan of @bluwy in the end, sorry if my comments sound strong. I think we are coming from different contexts and what i am chasing for Also for Astro's sake, while probably it is totally not my position to say any comments or what is best or not, since |
Astro users struggle with environment variables so I am eager to arrive on a solution as well. I want to bring the full picture into the conversation first. We have dev, build, and runtime to care of.
I am currently of the opinion that we should let the adapter - if not the user themselves - make the decision to add to |
@pi0 I don't find your comment sounding strong, and same here, trying to have a healthy discussion 🙂 About I don't think it's likely we'll see
I think IMO I don't think there's something |
Thanks for your points @bluwy. Yes, we are mainly talking about "accessing environment variables" at least for Yes I also agree that As for |
astro is really bad/inconsistent at handling this. i thought, 5d71a00 would fix it, but no. now dev is broken. there is already an issue for getting this fixed: withastro/astro#9827 i hope they can deal with this in a somewhat timely manner, so we don't need to rely on such hacks anymore
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Astro Info
If this issue only occurs in one browser, which browser is a problem?
No response
Describe the Bug
Astro seems to have the concept of
process.env
on the server, but it doesn't populate it with stuff from.env.local
for example. This is reaally annoying for library authors trying to automatically infer values for their users. If there is aprocess.env
, we usually chooses to got with that, and only falling back toimport.meta.env
if that fails (for example iftypeof process === "undefined"
)What's the expected result?
either process not to exist or for the variables to be put there. this middleground seems very confusing...
Link to Minimal Reproducible Example
https://stackblitz.com/edit/github-hdhenl?file=src%2Fpages%2Fapi%2Fhello.ts
Participation
The text was updated successfully, but these errors were encountered: