-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
feat: Consistent handling of environment variables #5663
feat: Consistent handling of environment variables #5663
Conversation
🦋 Changeset detectedLatest commit: a5e3a87 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
…-sejohnson/kit into 4296/sejohnson-environment-variables
Added runtime variable support. |
Co-authored-by: Ben McCann <[email protected]>
Co-authored-by: Ben McCann <[email protected]>
Co-authored-by: Ben McCann <[email protected]>
Co-authored-by: Ben McCann <[email protected]>
Co-authored-by: Ben McCann <[email protected]>
I had to revert to version 70 (previous) because this version 71 was making my netlify function crash saying For ref, I am using the netlify adapter without any option, so all defaults. |
@campbell-hay it sounds like you upgraded |
@benmccann Oh good to know, my kit was 392 when it was not working with netlify adapter 71, now my kit 396. That means I could bump up the adapter to version 71 again then ? |
Yes |
- Update code to use new env var modules provided by Svelte Kit - Remove obsolete /env endpoint for loading env vars - Remove obsolete env store - Add .env file for default public dynamic env vars - Add PublicEnv interface for declaring the pubic env vars - Use vite preview for running production build so .env is used for e2e tests - See: sveltejs/kit#5663
- Update code to use new env var modules provided by Svelte Kit - Remove obsolete /env endpoint for loading env vars - Remove obsolete env store - Add .env file for default public dynamic env vars - Add PublicEnv interface for declaring the pubic env vars - Use vite preview for running production build so .env is used for e2e tests - See: sveltejs/kit#5663
Looks like the runtime variables are missing from the documentation. Is that how we would load optional variables though? loading from the dynamic/static gives an error during the build if the variable doesn't exist. |
https://kit.svelte.dev/docs/modules#$env-dynamic-private Dynamic is runtime. You're likely importing it incorrectly -- dynamic only exports one object, |
How to make conditional reading of environment values between private/public scopes based on I tried do it like this, but I've got import { browser } from '$app/env';
import { PUBLIC_MY_VALUE } from '$env/static/public';
const getMyValue = () => {
if (browser) return PUBLIC_MY_VALUE;
return import('$env/dynamic/private').then(({ env }) => env.MY_VALUE);
}; |
@orlov-vo It defeats the point of private scoped variables if you can import them on the client, would you not be better off doing whatever logic you need to do in an endpoint with the private variable then just using the public one on the client? |
You cannot. We completely disallow imports of |
@tcc-sejohnson How do you validate your env vars? I saw you mention that in your initial design proposal, I'm interested in doing that as well. I think this should be in the docs too. |
That was something we decided to leave up to userland, though we solved some of it by accident. For the static modules, because you're importing the variables by name, if they're not defined at buildtime, your build will error. For dynamic vars, you can build an "env var validator" module, import it into |
@tcc-sejohnson Just noticed this when deploying with the new changes. That's awesome! I feel like this should still be documented though imo, would be really useful to know that for static vars, build will error out if they're undefined. |
This feature work only in preview? Not with npm run dev? |
- Update code to use new env var modules provided by Svelte Kit - Remove obsolete /env endpoint for loading env vars - Remove obsolete env store - Add .env file for default public dynamic env vars - Add PublicEnv interface for declaring the pubic env vars - Use vite preview for running production build so .env is used for e2e tests - See: sveltejs/kit#5663
- Update code to use new env var modules provided by Svelte Kit - Remove obsolete /env endpoint for loading env vars - Remove obsolete env store - Add .env file for default public dynamic env vars - Add PublicEnv interface for declaring the pubic env vars - Use vite preview for running production build so .env is used for e2e tests - See: sveltejs/kit#5663
Will close #4296 when finished.
This is a rough draft of the static environment variables solution. It adds a new config option:
config.kit.env.publicPrefix
, which defaults toPUBLIC_
. Runningsvelte-kit sync
will now dump allpublicPrefix
-prefixed environment variables to$app/env
, and all variables not prefixed to$app/env/private
. It also creates types for these files (for autocompletion).Additionally, it adds a neat new feature that prevents importing
$app/env/private
into any client-side code by analyzing the import module graph during bothdev
andbuild
. Initially, I had concerns around catching dynamic imports, but it seems this solution does a great job at that.There are some rough edges -- I especially hate the amount of duplication between the Rollup and Vite algorithms in
vite/utils.js
. I'm sure there's a smarter way to structure that, but I've been screwing around with import graphs for too long right now to see it.Update: Added support for the runtime variables part of the proposal.
Runtime variables are now exposed via
import { env } from '$app/env/runtime'
.env
is typed asApp.RuntimeEnv
, which is just a convenience for developers (they can define what they expect the runtime env to be in order to provide intellisense when importing the module). This module is populated by callingset_env
, which is itself called fromserver.init
. Adapters are responsible for callingserver.init
when it is appropriate. Foradapter-node
(which I have updated as part of this PR for testing), this would be on startup.Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. All changesets should bepatch
until SvelteKit 1.0