environment variables error

[fhrancoo]

Astro Info

No hay mensaje de errores.

Describe the Bug

@astrojs/cloudflare >10.0.0 no carga las variables de entorno cuando envias a produccion en cloudflare pages. la v9.2.1 si esta funcionando bien, pero en >10.0.0 esta fallando.

What's the expected result?

En cloudpages deberia cargar las variables de entorno.

Link to Minimal Reproducible Example

https://www.cloudflare.com/

Participation

• [ ] I am willing to submit a pull request for this issue.

[alexanderniebuhr]

Please add a minimal reproducible example or the issue will be closed after 3 days. Thank you!

[fhrancoo]

adjunto un ejemplo minino.

example error on production

example error repo on git

[alexanderniebuhr]

Thanks for the example, the observed behavior you see is expected, since Astro replaces import.meta.env with process.env calls if the environment variables are not defined inside a .env files. We are currently looking into making our docs more clear, and the upcoming Astro env RFC should make this easier. For the time being I would suggest using Astro.locals.runtime.env, instead of import.meta.env. An alternative would be to add a .env file to the repository.

[EskelCz]

Thanks for the example, the observed behavior you see is expected, since Astro replaces import.meta.env with process.env calls if the environment variables are not defined inside a .env files. We are currently looking into making our docs more clear, and the upcoming Astro env RFC should make this easier. For the time being I would suggest using Astro.locals.runtime.env, instead of import.meta.env. An alternative would be to add a .env file to the repository.

I'm sorry but I don't follow. I have a public repository and using import.meta.env in a few .js files, outside of Astro. What am I to do? My app broke with the update to v10 and I don't see a clear way out. :(

[alexanderniebuhr]

In that case you need to have a .env file available during build time. That means if you build your project with the GitHub Cloudflare App, you need to that file to the repository.

[EskelCz]

@alexanderniebuhr Thanks for the reply, but are you suggesting that I should add my secret keys into a public repository? I'm building the website using a GitHub Action/CI. What's the purpose of having the keys in CloudFlare Page settings? I'm really confused and contemplating reverting to v9.

EDIT: Can't do that either, the CI started to break when deploying...

✨ Upload complete!

20:03:47.966 | Success: Assets published! 20:03:49.412 | Error: Failed to publish your Function. Got error: Uncaught TypeError: Fm.default is not a constructor at functionsWorker-0.2225597838889648.js:4541:630 in Vl at functionsWorker-0.2225597838889648.js:4599:23 in Kl

So I guess I have to either solve the .env issue, or leave CloudFlare :(

[alexanderniebuhr]

Are you suggesting that I should add my secret keys into a public repository

No I'm not suggesting this, your secret keys should not be accessed by import.meta.env, that is unsafe. Secret keys should be defined as encrypted secret in Cloudflare and be access using Astro.runtime.locals.env. There is an open RFC for Astro core, which tries to solve this, but I personally would not use import.meta.env for secrets.

[EskelCz]

@alexanderniebuhr Ok but both my front-end and back-end are importing js files that need the .env variables (some public, some private). Those files don't have access to Astro and rely on Vite.

I don't see how import.meta.env was unsafe, but that's beside the point now. I just need to get it running. For reference, this is my repo https://github.com/AndorCz/andor2

My issue (error 500) is probably coming from here: https://github.com/AndorCz/andor2/blob/main/src/lib/database.js

[alexanderniebuhr]

Pass the secret key from the middleware to the function, I guess.

[EskelCz]

Right, that's the easy part, ok. But for the front-end I don't see a solution.

[alexanderniebuhr]

So if you need a key in the client js bundle, than it can't be a secret, it will be exposed in the source-code anyways. If it is only needed inside the SSR part, then you should be able to pass it from locals too.

[EskelCz]

Ok, true, but the developer experience is pretty bad. First I'm going to be pasting the keys into random places in the codebase, then I'm going to be spammed by "GitGuardian" for a security flaw in the repo, however untrue.

But I guess it's workable, thanks for helping me through it, at least I know I'm not missing some better way.

[EskelCz]

Also it doesn't allow for changing the env variables based on context, without changing the code. Kind of defeats the purpose of both "environment" and "variables".

[alexanderniebuhr]

Also it doesn't allow for changing the env variables based on context, without changing the code. Kind of defeats the purpose of both "environment" and "variables".

Same is true for import.meta.env though. import.meta.env inlines variables as strings during build time, if you need to have them variable based on runtime factors, you should access them by Astro.locals.runtime.env and pass that to your other files. For Cloudflare env vars need to be scoped to the request and not globally.

[EskelCz]

Actually I found out it was something else, the env variables are being saved at the build time correctly, so that part didn't break. No idea why but I'm glad. :) I wish I knew about the new Real-time Logs feature yesterday...