feat: allow $env to be used outside Vite context
#15250
Closing issue
Describe the problem
You can't use code in lib/db to setup your e2e tests if it uses $env because Vite doesn't run in the Playwright context
Describe the proposed solution
Replace virtual modules with generated modules
Alternatives considered
No response
Importance
would make my life easier
Additional Information
No response
Pull request
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.I noticed our test apps had tests in a "test" folder instead of "tests" (plural). Is that on purpose? Or should we include both variations in the generated tsconfig.json in case of mistakes like this? created#15254
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
- It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
- This message body should clearly illustrate what problems it solves.
- Ideally, include a test that fails without this PR but passes with it.
Tests
- Run the tests with
pnpm testand lint the project withpnpm lintandpnpm check
Changesets
- If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running
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
- Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.
Info
![changeset-bot[bot]](https://avatars.githubusercontent.com/in/28616?v=4)
🦋 Changeset detected
Latest commit: 2e937dc
The changes in this PR will be included in the next version bump.
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 noticed our test apps had tests in a "test" folder instead of "tests" (plural). Is that on purpose? Or should we include both variations in the generated tsconfig.json in case of mistakes like this?
I don't know if one vs the other is better. sv doesn't create other, so I'm not sure we've decided on a preference as a group. If I search the SvelteKit node_modules it seems that test is way more popular than tests. I don't have any objection to including both variations so that users can choose which they prefer
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?
I guess only the STATIC secrets need to be? Because presumably the DYNAMIC secrets get read from .env on disk. The STATIC secrets already get embedded into the build output, so I don't think this is anything new or anything to worry about
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
Are there plans to include $app/environment too?
Are there plans to include $app/environment too?
Yes, but I'm wondering if it's just about making everything in $app/* importable or if folks want to be able to mock them more easily too. Let's continue the discussion in #1485 (comment)
@benmccann do we still want to merge this into the version-3 branch instead of main?
do we still want to merge this into the version-3 branch instead of main?
I don't have strong feelings either way. I'm curious if @Rich-Harris and the rest of the team think it's better to hold it back for marketing impact or just get it out there sooner
we still need to load them because we exclude $env during build
• Feb 4, 2026, 11:20 AMPro tip: You can prefix GitHub URLs of issues, PRs or discussions with svcl.dev/ to view them on this page! Also try it on a GitHub release ;)