breaking: serve public env dynamically, prevent use of dynamic env vars during prerendering

[Rich-Harris]

Fixes #10008. This does two things:

• prevents the use of $env/dynamic/public while prerendering (use $env/static/public instead)
• when landing on a prerendered page, populates $env/dynamic/public from a new dynamically rendered /_env.js module, instead of populating it with stale build-time values

TODO:

• allow %sveltekit.env.PUBLIC_WHATEVER% to continue working (seems reasonable that this would be an exception to the 'you can't use dynamic public env vars during prerendering' rule)
• nicer code
• I guess it also makes sense to prevent use of $env/dynamic/private during prerendering
• docs
• preload _env.js when prerendering if we detect that $env/dynamic/public is used somewhere in the app
• make _env.js configurable, via config.kit.env.publicModule
• provide an API for adapter-static (and other adapters, if they want) to generate the _env.js module at build time
• some tests, i guess

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 test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[changeset-bot]

🦋 Changeset detected

Latest commit: d4f7ce2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@sveltejs/kit	Major
@sveltejs/adapter-static	Major

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

[dummdidumm]

I just realized that the adapter-static case is a bit weird. So far we had minors for all the adapters to tell "hey we support SvelteKit 2.0 as well". adapter-static should also get that treatment for the current version, but that is swallowed by this major bump now. We should create a minor release for adapter-static from master to circumvent that.

[Rich-Harris]

Is there much value in an adapter-static minor? If the only new feature is SvelteKit 2 support, why not just do a major version?

[dummdidumm]

True, if someone upgrades to SvelteKit 2 they might as well upgrade to adapter-static v3. We should add that to the migration script though (auto-bump the adapter-static version)

[dummdidumm]

If you want to do the _app change (and if it's easy) feel free to do so, else I think this is good to merge.

[CaptainCodeman]

I guess it also makes sense to prevent use of $env/dynamic/private during prerendering

I think this might be incorrect. Even with prerendering disabled it now prevents any handle fn in hooks.server.ts from making use of dynamic env values, which might be needed at runtime.

My specific use-case is using the @sveltejs/adapter-node node adapter, and the env defines the 'ROOT_DOMAIN' that the site is serving, for instance .example.com, so that requests to site-one.example.com can load the appropriate site context by site ID, and redirect to the site's "proper" custom domain if it has one set. When the same request is made via the custom domain, it loads the site based on the domain name instead and doesn't redirect.

The ROOT_DOMAIN isn't known at build time - the same docker image can be deployed to environments that have different values (testing, staging, production).

The build initially compiles OK but then errors at the pre-render stage even with pre-rendering disabled:

+layout.server.ts:

export const prerender = false

Build output:

vite v5.0.9 building SSR bundle for production...
✓ 88 modules transformed.

vite v5.0.9 building for production...
✓ 62 modules transformed.
.svelte-kit/output/client/_app/version.json                                  0.03 kB │ gzip:  0.05 kB
.svelte-kit/output/client/.vite/manifest.json                                2.66 kB │ gzip:  0.53 kB
.svelte-kit/output/client/_app/immutable/chunks/stores.OXeE6BI3.js           0.24 kB │ gzip:  0.17 kB
.svelte-kit/output/client/_app/immutable/nodes/1.a7topCIA.js                 0.79 kB │ gzip:  0.50 kB
.svelte-kit/output/client/_app/immutable/nodes/0.VoE1dcHf.js                 0.89 kB │ gzip:  0.58 kB
.svelte-kit/output/client/_app/immutable/chunks/preload-helper.0HuHagjb.js   0.91 kB │ gzip:  0.56 kB
.svelte-kit/output/client/_app/immutable/chunks/scheduler.k-kUyWhY.js        2.16 kB │ gzip:  1.02 kB
.svelte-kit/output/client/_app/immutable/nodes/2.YZTI5OQK.js                 2.48 kB │ gzip:  1.24 kB
.svelte-kit/output/client/_app/immutable/chunks/singletons.i1C8PUYA.js       2.92 kB │ gzip:  1.48 kB
.svelte-kit/output/client/_app/immutable/entry/app.WtRj-Ezm.js               5.20 kB │ gzip:  1.97 kB
.svelte-kit/output/client/_app/immutable/chunks/index.wJJws_a0.js            5.24 kB │ gzip:  2.21 kB
.svelte-kit/output/client/_app/immutable/entry/start.OF9vDRZY.js            28.00 kB │ gzip: 11.17 kB
✓ built in 404ms

node:internal/event_target:1006
  process.nextTick(() => { throw err; });
                           ^
Error: Cannot read values from $env/dynamic/private while prerendering (attempted to read env.HOST_DOMAIN). Use $env/static/private instead
    at Object.get (file:///Users/simon/dev/temp/sk-envs/.svelte-kit/output/server/index.js:3664:11)
    at file:///Users/simon/dev/temp/sk-envs/.svelte-kit/output/server/chunks/hooks.server.js:17:33
    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:526:24)
    at async Server.init (file:///Users/simon/dev/temp/sk-envs/.svelte-kit/output/server/index.js:3696:24)
    at async prerender (file:///Users/simon/dev/temp/sk-envs/node_modules/.pnpm/@[email protected]_@[email protected][email protected][email protected]/node_modules/@sveltejs/kit/src/core/postbuild/prerender.js:102:2)
    at async MessagePort.<anonymous> (file:///Users/simon/dev/temp/sk-envs/node_modules/.pnpm/@[email protected]_@[email protected][email protected][email protected]/node_modules/@sveltejs/kit/src/utils/fork.js:22:16)
Emitted 'error' event on Worker instance at:
    at [kOnErrorMessage] (node:internal/worker:290:10)
    at [kOnMessage] (node:internal/worker:301:37)
    at MessagePort.<anonymous> (node:internal/worker:202:57)
    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:731:20)
    at exports.emitMessage (node:internal/per_context/messageport:23:28)

Node.js v18.10.0

It's possible to workaround it by adding tests for building before accessing the values, hopefully that helps anyone who has the same issue and finds this.

Scratch that: I think it was all down to me accessing it outside of the handle function itself (preparing some strings). I'll leave this just in case someone else trips over the same thing.

[ollema]

@CaptainCodeman this does seem to be an issue, see #11341.

was there a workaround? if so, could you share it in #11341 perhaps? I did not quite understand the building stuff you referred to