Environment variables let you store important settings outside your code. This keeps secrets safe and makes your app flexible for different places.
Environment variables ($env) in Svelte
import { env } from '$env/dynamic/public'; console.log(env.PUBLIC_API_URL);
Use $env/dynamic/public to access public environment variables in the browser.
Variables starting with PUBLIC_ are safe to expose to the client.
import { env } from '$env/dynamic/public'; console.log(env.PUBLIC_API_URL);
import { env } from '$env/static/private'; console.log(env.SECRET_KEY);
import { env } from '$env/static/public'; console.log(env.PUBLIC_BASE_URL);
This Svelte component shows how to display a public environment variable in the page.
<script> import { env } from '$env/dynamic/public'; </script> <main> <h1>API URL:</h1> <p>{env.PUBLIC_API_URL}</p> </main>
Always prefix public environment variables with PUBLIC_ to expose them safely.
Private variables are only available on the server and never sent to the browser.
Use $env/static imports for better performance when variables don't change.
Environment variables store settings outside your code for safety and flexibility.
Use $env/dynamic/public to access public variables in the browser.
Prefix public variables with PUBLIC_ to share safely with client code.
Practice
Solution
Step 1: Understand environment variables purpose
Environment variables keep sensitive or changeable settings outside the main code, so you can change them without editing code.Step 2: Connect to safety and flexibility
This separation helps keep secrets safe and lets you adjust settings easily for different environments like development or production.Final Answer:
To store settings outside the code for safety and flexibility -> Option DQuick Check:
Environment variables = safety and flexibility [OK]
- Thinking environment variables speed up the app
- Believing environment variables are for code organization only
- Confusing environment variables with libraries
Solution
Step 1: Identify public environment variable import
Public variables are accessed from '$env/static/public' when known at build time.Step 2: Match variable prefix and import path
Public variables must start with 'PUBLIC_' and be imported from '$env/static/public' for static access.Final Answer:
import { PUBLIC_API_KEY } from '$env/static/public'; -> Option AQuick Check:
Public vars use static/public import [OK]
- Using private import paths for public variables
- Forgetting the PUBLIC_ prefix
- Mixing dynamic and static imports incorrectly
import { PUBLIC_APP_NAME } from '$env/static/public';
<h1>Welcome to {PUBLIC_APP_NAME}!</h1>
Solution
Step 1: Understand import of PUBLIC_APP_NAME
The variable PUBLIC_APP_NAME is imported from '$env/static/public', so its value is available at build time.Step 2: Check usage in template
The variable is used inside the <h1> tag, so it will display the actual value 'MyApp'.Final Answer:
<h1>Welcome to MyApp!</h1> -> Option AQuick Check:
Static public env var shows actual value [OK]
- Expecting variable name instead of value
- Assuming variable is undefined without import
- Confusing static and dynamic imports
import { SECRET_KEY } from '$env/static/private';
console.log(SECRET_KEY);
But you get an error during build. What is the likely cause?Solution
Step 1: Understand private env variable usage
Private environment variables are only available on the server side and cannot be imported into client-side code.Step 2: Recognize build error cause
Importing private variables in a component that runs in the browser causes build errors because secrets must stay server-only.Final Answer:
Private variables cannot be imported in client-side code -> Option CQuick Check:
Private vars are server-only [OK]
- Adding PUBLIC_ prefix to private vars
- Using dynamic public import for private vars
- Assuming missing .env declaration causes build error
PUBLIC_GREETING. You also want to update this message without rebuilding the app. Which approach should you use?Solution
Step 1: Understand static vs dynamic public env variables
Static public variables are fixed at build time, so changes require rebuilding the app.Step 2: Use dynamic public env for runtime updates
Dynamic public variables from '$env/dynamic/public' reflect environment changes without rebuilding, ideal for updating messages.Final Answer:
Import PUBLIC_GREETING from $env/dynamic/public and use it in your component -> Option BQuick Check:
Dynamic public env allows runtime updates [OK]
- Using static public import for dynamic needs
- Storing env vars in local variables without import
- Hardcoding messages instead of using env vars
Ready to prove it?
Pass the test and this pattern moves unknown
