Post

The new #sveltekit explicit environment variables are really great! But one thing that has been bothering me, is how to handle missing env variables during build time. We just found a nice solution that you might want to use as well. 1/ #svelte

Mat Simon

@matsimon.dev

The docs suggest to make them optional during building, but the downside is that you then need to handle the optional type all over the code since the type of the variable will be `undefined | string`. Although this is technically correct it's not great DX and unnecessary during runtime. 2/

10/7/26, 11:43 am0 reposts0 likes

Mat Simon

@matsimon.dev

10 July

This runtimeOnly schema wrapper does two things: 1. It makes the value optional during build, but doesn't make the return type optional. 2. It transforms the value to an Error during build, so that _if_ it is accessed, it will be very apparent and the build will fail in all likelihood

rich harris

@rich-harris.dev

10 July

have you tested to see what happens when you access a runtime-only variable at build time? it won't throw an error, the value will just _be_ an error. FWIW we're looking into doing something like this github.com/sveltejs/kit...

github.combreaking: replace `EnvVarConfig.static` with `EnvVarConfig.availability` by dummdidumm · Pull Request #16267 · sveltejs/kitThe static: boolean property on environment variable configs has been replaced by availability, which has four possible values: 'dynamic' (default, equivalent to the old static: false) — t...

Mat Simon

@matsimon.dev

10 July

Oh nice! That PR looks great. But this will not solve the issue of accessing a runtime env var during build, right?

rich harris

@rich-harris.dev

10 July

it would make it `undefined` at build time without you having to muck about with the schema. the trade-off of course is that the types will reflect that — runtime only vars would be `string | undefined`

Mat Simon

@matsimon.dev

10 July

Yes! We tried proxying the access and actually throw, but this just throws whenever it’s imported not when it’s used (since that’s not a feature JS supports - same problem as with signals). It’s not perfect but in all use cases we thought of this caused the build code to fail with a useful message.