feat: simplify custom entrypoint stuff - #16560
Merged
Merged
Conversation
|
Install the latest version of pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/9ea497728396143e767fd15ea42fea85be0378dfOpen in |
|
6 tasks
Contributor
There was a problem hiding this comment.
Additional Suggestions:
- Prerender/fallback import the custom handler from the stale
server/index.jspath, which no longer exists after the build output was renamed toserver/handler.js
- Fallback page generation imports the custom handler from the non-existent
server/index.jsafter the build entry key was renamed tohandler
Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
Member
|
/autofix |
… clientAddress during prerendering` for normal requests because the dev SSR handler wires up a prerender-style throwing stub instead of returning the request's socket address.
This commit fixes the issue reported at packages/kit/src/exports/vite/dev/index.js:599
## Bug
Commit `8f22bf0` ("pass getClientAddress directly") reworked how `getClientAddress` is provided to the SSR handler. In the **preview** server this was done correctly — the per-request `respond` wrapper now injects:
```js
getClientAddress: () => {
const { remoteAddress } = req.socket;
if (remoteAddress) return remoteAddress;
throw new Error('Could not determine clientAddress');
}
```
But in the **dev** server (`packages/kit/src/exports/vite/dev/index.js`), the same refactor pasted the *prerender* implementation into the request-handling wrapper:
```js
getClientAddress: () => {
throw new Error('Cannot read clientAddress during prerendering');
},
```
This wrapper is the one used for real dev requests (it's created per request inside the Vite middleware, where `req` is in scope). So any app that calls `event.getClientAddress()` in a load function, endpoint, or hook now throws `Cannot read clientAddress during prerendering` under `vite dev` — a nonsensical error for a live request, and a regression from the previous behavior where the real socket address was returned.
### Concrete trigger
Run `vite dev` and hit any route whose `load`/endpoint/hook calls `event.getClientAddress()`. Instead of the client IP, the request fails with `Cannot read clientAddress during prerendering`.
## Fix
Replace the throwing stub in the dev handler's `respond` wrapper with the same socket-based implementation used by the preview server. `req` is already in closure scope because the `Server` and its wrapper are constructed per request inside the middleware.
The preview server (`packages/kit/src/exports/vite/preview/index.js`) already provides `getClientAddress` correctly after `8f22bf0`, so no change is needed there.
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: Rich-Harris <hello@rich-harris.dev>
…ejs/kit into feat-server-entrypoint-alt
teemingc
approved these changes
Jul 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
continuation of #16464. This isn't complete — the types need a little finessing (in the handler, it probably doesn't make sense for
serverto have aninitmethod, and the second argument toserver.respondshould be optional and only includeplatform), andgetClientAddressdoesn't currently work. But you get the idea