automatically replace $env variables with process.env in edge functions

[jdgamble555]

Describe the problem

Edge functions in Vercel do not work as expected. You have to specify the variable EXACTLY in process.env for it to work, while $env seem to get translated automatically in regular lambdas.

It would be nice if all $env variables were replaced with process.env so that I would not have to configure it manually with something like:

import { env } from '$env/dynamic/public';
import { createClient } from '@supabase/supabase-js';

const isLocal = Object.keys(env).length;

export const supabase = createClient(
    (isLocal ? env.PUBLIC_SUPABASE_URL : process.env.PUBLIC_SUPABASE_URL) as string,
    (isLocal ? env.PUBLIC_SUPABASE_ANON_KEY : process.env.PUBLIC_SUPABASE_ANON_KEY) as string
);

Describe the proposed solution

The vercel adapter does this if the edge: true is set.

Alternatives considered

My workaround code above.

Importance

would make my life easier

Additional Information

Obviously this would not be necessary if SvelteKit handled this internally, or if Vercel Edge functions handled env variables the same way as regular functions.

[Rich-Harris]

Basically, the process.env object in edge functions is only populated with the values that are read in the code as process.env.WHATEVER. This level of static analysis is obviously insufficient — there's now an internal Vercel issue to try and come up with a solution.

In the meantime, if you have the ability to use $env/static/... instead of $env/dynamic/... then that's a better solution since it bypasses that process — the values are replaced at build time, improving bundle size and performance (no object lookups) and allowing optimisations like dead code elimination.

Removing the 1.0 milestone since it's a platform issue rather than a SvelteKit one.

[jdgamble555]

Ok, thanks for the update. In my case, this was okay (with Supabase):

import { PUBLIC_SUPABASE_ANON_KEY, PUBLIC_SUPABASE_URL } from '$env/static/public';

J

Good to know Vercel is working on getting everything working the same across environments.

[leerobert]

Can confirm this is how I set up my supabaseClient.ts for vercel deployment:

import { createClient } from '@supabase/auth-helpers-sveltekit';
// import { env } from '$env/dynamic/public';
import { PUBLIC_SUPABASE_ANON_KEY, PUBLIC_SUPABASE_URL } from '$env/static/public';

//export const supabase = createClient(env.PUBLIC_SUPABASE_URL, env.PUBLIC_SUPABASE_ANON_KEY);
export const supabase = createClient(PUBLIC_SUPABASE_URL, PUBLIC_SUPABASE_ANON_KEY);

[MiraiSubject]

I also ran into this issue recently, however even when following the documentation and setting envVarsInUse with my array of environment variables I want to be accessible to the edge function they are still not available.

From the sveltekit docs:

From the vercel docs:

My svelte.config.js: https://github.com/MiraiSubject/sveltekit-env-vars-repro/blob/1be777331b3b34d0744f76f980a82c818757f311/svelte.config.js#L16-L24

However this simple repro shows that even that is non-functional.

On vercel before building the project I have specified the environment variables like this:

But in the deployment: https://sveltekit-env-vars-repro.vercel.app/ only the VERCEL_REGION gets printed.

I noticed that both of the documentations mention edge: true which has been changed to `runtime: 'edge', so maybe something might have been changed in the behaviour of this as well?

Am I potentially missing something here or does envVarsInUse just not work at all anymore for Vercel?

Either way if the dynamic option really doesn't work, it's going to be difficult for us to maintain both a Vercel and self-hosted docker image, where in the latter case consumer should supply their own keys.

Edit: I just noticed that just plainly using process.env.VARNAME in the server files works to replicate the "dynamic" behaviour, but you lost svelte's types then obviously.

[MiraiSubject]

As of @sveltejs/adapter-vercel@3.0.0 https://github.com/sveltejs/kit/releases/tag/%40sveltejs%2Fadapter-vercel%403.0.0 Environment variables in $env/dynamic/private and $env/dynamic/public now work as expected.

I updated the repro repo with these version bumps and was able to observe the expected environment variables. I did remove the Vercel deployment so I don't expose my other vercel variables.

This can be closed now because #9942 fixes the issue.

Thanks for resolving the issue!