chore: get rid of __sveltekit/* - #16813
Conversation
|
Install the latest version of pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/5c310793785ed8362c595295829c0625cb7d1030Open in |
🦋 Changeset detectedLatest commit: 5c31079 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 |
…odule path, so it never matches and is always `false`.
This commit fixes the issue reported at packages/kit/src/exports/vite/index.js:1773
## Bug
In `packages/kit/src/exports/vite/plugins/env-vars.js`, this PR moved the generated env directory:
```js
dir = posixify(
path.resolve(c.root, config.outDir, `generated/${is_build ? 'build' : 'dev'}/env`)
);
```
So in build mode the client env module is written to `${out_dir}/generated/build/env/public/client.js`.
But `packages/kit/src/exports/vite/index.js:1773` still looked up the pre-PR path:
```js
chunk.modules[`${out_dir}/generated/env/public/client.js`]
```
`chunk.modules` keys are absolute module paths, and `out_dir === posixify(kit.outDir)` matches the base env-vars.js resolves against — so the only difference is the missing `build/` segment. This block runs during the client build (`is_build` is always true here, consistent with line 461 which uses `generated/${is_build ? 'build' : 'dev'}`), so the lookup can never match.
## Impact
`uses_env_dynamic_public` becomes stuck at `false`. It is stored in `build_data.client` (lines ~1801 and ~1849) and controls whether the runtime prerendered public env module is loaded at runtime. Apps that import `$app/env/public` on the client **and** use dynamic (non-static) public env vars would silently get stale/missing runtime env values — a regression versus before this PR, where the path matched.
## Trigger
Build an app that imports `$app/env/public` in client code with at least one `public && !static` env var configured. Previously the chunk-module lookup matched and `uses_env_dynamic_public` was `true`; now it always resolves `false`.
## Fix
Updated the lookup to the new build-mode path:
```js
chunk.modules[`${out_dir}/generated/build/env/public/client.js`]
```
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: Rich-Harris <hello@rich-harris.dev>
cc47fbb to
a3296b3
Compare
…` instead of `generated/dev/`, so it never updates the module that is actually imported
This commit fixes the issue reported at packages/kit/src/exports/vite/dev/index.js:457
## Bug
In `packages/kit/src/exports/vite/dev/index.js`, the `watcher.on('all', ...)` handler regenerates the server module when `app.html`, `error.html`, `service-worker`, or `hooks.server` change:
```js
write_server(svelte_config, path.join(svelte_config.outDir, 'generated'), root);
```
This passes `<outDir>/generated` as the output directory. But in dev, every other part of the system uses `<outDir>/generated/dev`:
* `sync.create(config, root, manifest_data, /* is_build */ false)` computes `output = path.join(config.outDir, 'generated/dev')` and calls `write_server(config, output, root)` (`sync.js:25-29`).
* The Vite `<sveltekit:generated>` alias resolves to in dev (`exports/vite/index.js:455`).
* The dev SSR entry imports from `generated/dev/client/...` (`dev/index.js:179,189`).
So `write_server` from the watcher writes to `generated/server.js` and `generated/shared/error-template.js`, while the module actually imported at runtime lives at `generated/dev/server.js`.
## Trigger
Editing `src/app.html`, `src/error.html`, `src/hooks.server.js`, or the service worker file during `vite dev`. The watcher fires and regenerates into the wrong directory, so the running server keeps serving the stale `generated/dev/server.js`. The change only takes effect after a full dev-server restart (which runs `sync.create` with the correct `generated/dev` path).
## Fix
Pass `path.join(svelte_config.outDir, 'generated', 'dev')` so the watcher writes to the same location `sync.create(..., false)` writes to and that the alias imports from.
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: Rich-Harris <hello@rich-harris.dev>
teemingc
left a comment
There was a problem hiding this comment.
Nice! Added some small notes. Looking forward to more cleaning up of the vite/index.js file 😄
| ...builder.environments.client.config.define, | ||
| ...builder.environments.serviceWorker.config.define | ||
| }; | ||
| ...builder.environments.serviceWorker.config.define, |
There was a problem hiding this comment.
Just to note: Sapphi mentioned changing config options after the configResolved hook isn't recommended and isn't guaranteed to work in the future. That said, I filed vitejs/vite#22092 a while back and the recommendation was to use virtual modules in the meantime 😅 I think it's better if we break free from virtual modules though.
| /** Internal version of $app/paths */ | ||
| declare module '__sveltekit/paths' { | ||
| export let base: '' | `/${string}`; | ||
| export let assets: '' | `https://${string}` | `http://${string}` | '/_svelte_kit_assets'; | ||
| export let app_dir: string; | ||
| export let relative: boolean; | ||
| export function reset(): void; | ||
| export function override(paths: { base: string; assets: string }): void; | ||
| export function set_assets(path: string): void; | ||
| } |
There was a problem hiding this comment.
As a follow-up, we should check if we can get rid of any mocks in packages/kit/vitest.kit.config.js and packages/kit/mocks. I think we can get rid of at least this __sveltekit/paths one.
Co-authored-by: Tee Ming <chewteeming01@gmail.com>
… more-generated-aliases
This PR gets rid of all the virtual modules, in favour of using real modules in
.svelte-kit/generated.Please 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