netlify edge functions SSR environment variable lookup

[saolsen]

What version of astro are you using?

1.5.0

Are you using an SSR adapter? If so, which one?

@astrojs/netlify/edge-functions

What package manager are you using?

npm

What operating system are you using?

Linux

Describe the Bug

Using import.meta.env with ssr and @astrojs/netlify/edge-functions doesn't work.
For example if you have some code that references import.meta.env.FOO.
The generated code has calls to process.env.FOO but to look up environment values in the netlify edge runtime it needs to call Deno.env.get("FOO").

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-gubo61?file=src/pages/index.astro

Participation

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

[bluwy]

This may be related to #4416 (comment)

[AirBorne04]

I have created a PR #5103 to address the access to runtime issue (for cloudflare). Is there a way to do a similar thing with Netlify too? Than we can generalize this a little more, since that should be a task for the adapter to handle.

[matthewp]

It probably can't be generic as each runtime does this a bit differently.

@bluwy is there any control we have over when import.meta.env compiles to? If so maybe there could be an option that the adapter controls for this.

[AirBorne04]

It probably can't be generic as each runtime does this a bit differently.

Sorry I did not mean to generalize what the adapter is doing, I meant the access to the specific runtime additions. Like ˋAstro.getRuntime()ˋ and each adapter can add to that runtime via a ˋSymbolˋ or ˋAstro.setRuntime()ˋ or even context, since it is also request related? I will adjust the draft PR.

[bluwy]

@bluwy is there any control we have over when import.meta.env compiles to? If so maybe there could be an option that the adapter controls for this.

Yeah it's currently being transformed to process.env.* at

astro/packages/astro/src/vite-plugin-env/index.ts

Line 37 in ef0c543

if (typeof process.env[key] !== 'undefined') return [key, `process.env.${key}`];

We could expose an adapter option to customize this. I think Cloudflare has a special case where functions env vars can only be accessed throught the env parameter, but this doc says otherwise that it can be read globally.

Either ways I think it would still be a win.

[matthewp]

@AirBorne04 we would need an RFC for a generic solution. Your current cloudflare-only PR I think is fine without one. That's a bit different from the environment variable problem being discussed here though.

[matthewp]

@bluwy oh, I didn't realize it was us. In that case I concur that an option that adapters can implement is the way to go here.

[matthewp]

Maybe build.envKey with a signature of (key: string) => string

[matthewp]

Rough usage example:

'astro:config:setup': ({ updateConfig, mode }) => {
  if(mode === 'build') {
    updateConfig({
      build: {
        envKey: (key: string) => `Deno.env.get("${key}")`
      }
    })
  }
}

[AirBorne04]

I think Cloudflare has a special case where functions env vars can only be accessed throught the env parameter, but this doc says otherwise that it can be read globally.

When deploying pages you need to access it via the function parameters. Only in the workers you can read them globally. Pages and workers are working very similar but unfortunately not exactly the same. I ran a quick test in pages and it outputs:

Attempted to access binding using global in modules.
[w:server] You must use the 2nd `env` parameter passed to exported handlers/Durable Object constructors, or `context.env` with Pages Functions.

so definitely functions parameter for the pages platform, for workers it is either function parameter or global.

[AirBorne04]

@AirBorne04 we would need an RFC for a generic solution. Your current cloudflare-only PR I think is fine without one. That's a bit different from the environment variable problem being discussed here though.

@matthewp just wondered if it makes sense to combine the env vars with the additional platform features or request contexts.

[matthewp]

@AirBorne04 I was talking about this with @bluwy, would it be possible, make sense for the adapter to assign the Env to a global so that it can be accessed via this envKey idea? Adapter would do something like:

const handler = (request, env) => {
  globalThis.WORKER_ENV = env;
  // ...
}

And then in the hook:

'astro:config:setup': ({ updateConfig, mode }) => {
  if(mode === 'build') {
    updateConfig({
      build: {
        envKey: (key: string) => `globalThis.WORKER_ENV["${key}"]`
      }
    })
  }
}

I know this is weird but I can't think of another way to wire up import.meta.env (which is what you want).

Am I right that the env is not different between requests?

[AirBorne04]

@matthewp Yes it is possible to assign them like this to a global. I am not sure how the envKey would be working just like this envKey("NETLIFY_SECRET")? And that would work with runtime specified env vars?

I know this is weird but I can't think of another way to wire up import.meta.env (which is what you want).

Actually i am not a fan of implicit merging of env variables into import.meta.env, cause it would be rather difficult to find the actual source of the definition. I would slightly adjust the naming to something like runtimeEnv(key: string) to be more explicit where they are defined.

Am I right that the env is not different between requests?

I checked this and the env vars are static per deployment