Skip to content

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

Merged
Rich-Harris merged 29 commits into
version-2from
env-dynamic-public
Dec 13, 2023
Merged

breaking: serve public env dynamically, prevent use of dynamic env vars during prerendering#11277
Rich-Harris merged 29 commits into
version-2from
env-dynamic-public

Conversation

@Rich-Harris

@Rich-Harris Rich-Harris commented Dec 12, 2023

Copy link
Copy Markdown
Member

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:

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-bot Bot commented Dec 12, 2023

Copy link
Copy Markdown

🦋 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

@Rich-Harris

Copy link
Copy Markdown
Member Author

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

dummdidumm commented Dec 13, 2023

Copy link
Copy Markdown
Member

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 dummdidumm left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

CaptainCodeman commented Dec 14, 2023

Copy link
Copy Markdown
Contributor

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/@sveltejs+kit@2.0.0_@sveltejs+vite-plugin-svelte@3.0.1_svelte@4.2.8_vite@5.0.9/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/@sveltejs+kit@2.0.0_@sveltejs+vite-plugin-svelte@3.0.1_svelte@4.2.8_vite@5.0.9/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

ollema commented Dec 16, 2023

Copy link
Copy Markdown

@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

elliott-with-the-longest-name-on-github pushed a commit that referenced this pull request Jul 15, 2026
…are unused (#16306)

closes #8946

The follow-up I promised in #16024, a few weeks late. Retargeting it
onto `version-3` turned it into a test, because the fix I wrote for
`main` is already there. The env embed sits behind the same
`client.uses_env_dynamic_public` check that the `$env/dynamic/public`
branch has used since #11277:

```js
if (client.uses_env_dynamic_public) {
	properties.push(`env: ${load_env_eagerly ? 'null' : devalue.uneval(env.rendered_env)}`);
}
```

What's left is the regression coverage. On kit 2 with
`experimental.explicitEnvironmentVariables` enabled, every
server-rendered page ships an `env: {}` object the client can never
read, since static values are inlined into the generated
`$app/env/public` module as literals. Rich said as much reviewing
#15934, "`rendered_env` is what gets sent from the server to the client.
`static` variables are already in the client".

One assertion added to the existing options-2 prerender test, so
version-3 can't regress into shipping the dead object again. Verified it
passes on `version-3` and that the same assertion fails on `main`
without the omitted fix.

---

### Please don't delete this checklist! Before submitting the PR, please
make sure you do the following:
- [x] 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
- [x] This message body should clearly illustrate what problems it
solves.
- [x] Ideally, include a test that fails without this PR but passes with
it.

### Tests
- [x] Run the tests with `pnpm test` and lint the project with `pnpm
lint` and `pnpm check`

### Changesets
- [x] 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:`.

### Edits

- [x] Please ensure that 'Allow edits from maintainers' is checked. PRs
without this option may be closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants