So whenever you're building an application,
you're probably gonna be dealing with some environment variables,
things like API keys and database credentials.
And these can be added to a .envfile.env when you're
developing locally so that you can know those secrets.
In this exercise, we want to allow the user to enter the website
if they know the correct passphrase using an environment variable.
So right now, if they know the passphrase, which is open sesame,
nothing happens, or at least nothing good happens.
Because we haven't declared that environment variable in our .env file, so
we'll do that now.
Create the passphrase, open sesame.
And now, inside our routes/page.server.js,
we can import that environment variable from the $env/static/private module.
And this is where they were getting kicked out
before cuz the data.get(passphrase) does not equal the hard-coded value.
We'll replace that hard-coded value with the environment variable.
And now, if you say open sesame into the input, I'm in.
Now, it's important that when you're dealing with environment variables,
that you don't accidentally expose them to the user,
because then they could be stolen, and that would not be good.
And SvelteKit actively prevents you from accidentally revealing your secrets.
If you try and import envas into your page.svelte component,
Sorry, I lost my scroll place.
If you try and import $env/static/private into your Svelte component,
then it's gonna break.
All right, we see this error message from Vite that says,
Cannot import $env/static/private into client-side code, right?
This is a server-only module, and there's a few server-only modules in SvelteKit.
Anytime you have a module that has the .server suffix,
page.server.js, layout.server.js, plus.server.js, or
any of your own modules that have a .server.js suffix.
And also any modules inside src/lib/server,
these are considered server modules that cannot be imported into client-side
code under any circumstances.
And so within those files, it's quite safe to access environment variables and
to communicate directly with your database.
And in turn, those modules can only be imported by other server modules.
You might be wondering why this module has such a funny name, $env/static/private.
The static part indicates that these values are known at build time.
And that means that they can be statically replaced, and
this enables useful optimizations.
For example, if you have a feature flag that is statically analyzed at build time,
then any code that is inside this block will just be removed altogether if
the feature flag is not currently enabled.
So where possible, we recommend using static environment variables, but
some cases, it might not be possible.
You might need to refer to environment variables that are not known
when your app is built, but are only known when your app is run, and for these,
we use dynamic environment variables.
So we have the same exercise as before, but this time,
we're gonna use dynamic environment variables instead of static ones.
First, we're gonna change the module that we're importing from to dynamic.
And we're gonna import env instead of PASSPHRASE because we don't know yet
what properties that env object is going to have.
And then down here, we're gonna replace PASSPHRASE with env.PASSPHRASE.
And now, as before, when we type in the passphrase, we get into the website.
So so far, we've been dealing with environment variables that are secret, and
they can only be accessed by certain modules.
But you might have some environment variables that are safe to
reveal to the user.
And these are distinguished from private environment variables by having a PUBLIC_
prefix, which you can configure in your svelte.config.
So in our .env file here, we're gonna set some public environment variables.
We'll pick a color like steelblue for the background and bisque for the foreground.
And then inside our component, we can, in fact, import these and
replace the hard-coded variables that we currently have.
So just delete all of that, and
import PUBLIC_THEME_BACKGROUND and
PUBLIC_THEME_FOREGROUND from
$env/static/public.
And now, when we reload this page,
it's pulling those values directly from our env file.
So we can change that and it will update the app.
And again, because we're pulling from a static env file,
those properties will be replaced in your code when the application is built.
Finally, of course, we can have dynamic public environment variables too.
Same as before, we're just gonna change the imports to env,
and grab that from the dynamic module instead.
And then we'll prefix all of these with env, same there.
And now, the application renders same as before.
Any questions about environment variables?
All right, well, I have some good news, we have finished the tutorial.
Congratulations, everyone, thank you for bearing with me,
this has been a lot of content to get through.
If you've made it the entire way through this tutorial,
you can now consider yourself a Svelte and SvelteKit expert.
You can start building apps on your own machines by just typing npm create-svelte
on the command line, follow the prompts,
that will set you up with a new application.
But this is not the end, Svelte and SvelteKit will continue to evolve,
we're always adding new features.
And as a consequence, this documentation will also evolve.
So I do encourage you to check back periodically and
see if there's new material.
And if you wanna keep up with developments in the Svelte world,
you can join our Discord server.
It's a very friendly space at svelte.dev/chat.
And you can follow Svelte Society on Twitter,
where you'll get a stream of updates on everything Svelte-related.
We are very happy to welcome you all to the Svelte community,
thank you for doing the tutorial with us.
And now, we're gonna move on to the final part of this workshop,
where we're gonna take everything that we've learned in the Svelte course and
the SvelteKit course and we're gonna build a full stack application.