feat: allow $env to be used outside Vite context #15250
Conversation
🦋 Changeset detectedLatest commit: 9cc1ebe The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
I don't know if one vs the other is better. |
I guess only the STATIC secrets need to be? Because presumably the DYNAMIC secrets get read from |
|
One last thought... Even though this isn't a breaking change, I would personally add it to the 3.0 milestone because it is highly demanded and I think that people are more likely to learn about it if it's part of the 3.0 release notes and it will make the 3.0 release more exciting |
| /** | ||
| * Load environment variables from process.env and .env files | ||
| * @param {import('types').ValidatedKitConfig['env']} env_config | ||
| * @param {string} mode | ||
| */ | ||
| export function get_env(env_config, mode) { | ||
| const { publicPrefix: public_prefix, privatePrefix: private_prefix } = env_config; | ||
| const env = loadEnv(mode, env_config.dir, ''); | ||
|
|
||
| return { | ||
| public: filter_env(env, public_prefix, private_prefix), | ||
| private: filter_env(env, private_prefix, public_prefix) | ||
| }; | ||
| } | ||
|
|
There was a problem hiding this comment.
This needs to be moved to a separate module to avoid type errors when users import $env/dynamic/* and they type check their code. We're currently using it in the generated module to avoid serialising users' dynamic env vars
|
Are there plans to include $app/environment too? |
Yes, but I'm wondering if it's just about making everything in |
| test.describe('$env access outside the Vite pipeline', () => { | ||
| test('$env/static/public', async () => { | ||
| const env = await import('$env/static/public'); | ||
| expect(env.PUBLIC_DYNAMIC).toBe('accessible anywhere/evaluated at run time'); | ||
| }); | ||
|
|
||
| test('$env/static/private', async () => { | ||
| const env = await import('$env/static/private'); | ||
| expect(env.PRIVATE_STATIC).toBe('accessible to server-side code/replaced at build time'); | ||
| }); | ||
|
|
||
| test('$env/dynamic/public', async () => { | ||
| const { env } = await import('$env/dynamic/public'); | ||
| expect(env.PUBLIC_DYNAMIC).toBe('accessible anywhere/evaluated at run time'); | ||
| }); | ||
|
|
||
| test('$env/dynamic/private', async () => { | ||
| const { env } = await import('$env/dynamic/private'); | ||
| expect(env.PRIVATE_DYNAMIC).toBe('accessible to server-side code/evaluated at run time'); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
We could also change these to Playwright component tests, which is what the majority of users are facing issues with.
3 participants
closes #15212
and helps with #1485
This PR writes the virtual env modules to disk so that they can be used in files that run outside of the Vite pipeline.
Some thoughts while implementing this:
It's not very nice that secrets can now exist in both the .env file and the generated module. But maybe it's fine because it's gitignored and bound to be overwritten when updated and sync runs?the dynamic module no longer serialises the .env filesvelte-kit syncused to only generate types but now it generates modules too so that we can use $env without starting the dev server.testdirectory in generatedtsconfig.json#15254Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.Edits