Skip to content

chore: test server directly - #16879

Draft
Rich-Harris wants to merge 7 commits into
server-respond-testsfrom
server-respond-tests-direct-call
Draft

chore: test server directly#16879
Rich-Harris wants to merge 7 commits into
server-respond-testsfrom
server-respond-tests-direct-call

Conversation

@Rich-Harris

Copy link
Copy Markdown
Member

Companion to #16872. I wanted to see if we can make direct calls to server.respond with no HTTP intermediary. For the most part it looks like we can, and in fact by doing so I learned that we respond to HEAD requests incorrectly by including a body (probably immaterial, since the body is likely discarded by any layer between the user and the server, including fetch itself, but still interesting to note).

Note that it requires us to explicitly pass accept: '*/*' (which fetch implies) and handle redirects ourselves.

@pkg-svelte-dev

pkg-svelte-dev Bot commented Aug 20, 2026

Copy link
Copy Markdown

Install the latest version of @sveltejs/kit from 4bea774:

pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/4bea7740859d2cf9d0e77ae5e51bc4e88f4bc24d

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/kit/pr/16879

@changeset-bot

changeset-bot Bot commented Aug 20, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 4bea774

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Comment on lines +53 to +55
if (event.request.method === 'HEAD' && response.body !== null) {
response = new Response(null, response);
}

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

there's definitely a better place for this to live, perhaps in the server.respond method. otherwise it'll end up duplicated all over

Comment on lines -280 to -286
test('invalid headers return a 500', async () => {
const response = await get('/endpoint-output/head-write-error');
expect(response.status).toBe(500);
expect(await response.text()).toMatch(
'TypeError [ERR_INVALID_CHAR]: Invalid character in header content ["x-test"]'
);
});

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Turns out this isn't testing anything in SvelteKit itself, it's just testing a Node.js behaviour

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Have a strong feeling we do things like this for a lot of tests... I'll try to get an agent to do a full pass through.

@svelte-docs-bot

Copy link
Copy Markdown

Comment thread packages/kit/vitest.kit.config.js Outdated
Comment on lines +65 to +67
// globalSetup: fileURLToPath(
// new URL('./test/apps/basics/unit-test/server.setup.js', import.meta.url)
// )

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I commented this out for the sake of my sanity but I do think we probably don't want to do this setup here, otherwise we'll be building the app twice — once for Vitest, once for Playwright. It should probably happen as part of the pnpm test:build script instead

@Nic-Polumeyv

Copy link
Copy Markdown
Contributor

Yeah. This is good. I'll go through this properly tomorrow.

@Nic-Polumeyv

Copy link
Copy Markdown
Contributor

The unit CI rows run vitest alone, so the globalSetup build is the only thing that creates .svelte-kit/output there. The double build only happens locally when running both suites back to back.

Stripping in server.respond also covers page routes, and leaves event.fetch alone, which never went through the HTTP layer in prod anyway.

@Nic-Polumeyv

Copy link
Copy Markdown
Contributor

Went through the rest of the suite for the same class. The only other candidate is request body can be read slow, where the body is an in-memory buffer under a direct Request, so nothing is slow anymore and the QUERY test covers the unconsumed-body delivery. Left it in. Everything else traces to kit code, including the platform-sounding ones (the Vite trailing-slash redirect and static-serving tests pin kit's preview middleware and allow-list).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants