Expose internal utilities for adapter authors building per-route workers

[max-lt]

Problem

SvelteKit builds a single monolithic manifest and Server instance. This works well for traditional deployments, but makes it hard for serverless runtimes that want to deploy routes as independent lightweight workers.

Adapter authors who want to build minimal per-route handlers currently have to reach into SvelteKit internals via path aliasing:

// Aliasing internal modules at build time
alias: {
  'sveltekit:cookie': join(process.cwd(), 'node_modules/@sveltejs/kit/src/runtime/server/cookie.js'),
  'sveltekit:routing': join(process.cwd(), 'node_modules/@sveltejs/kit/src/utils/routing.js')
}

This works but is fragile — these are undocumented internal paths that could break on any release.

Use case

I'm building OpenWorkers, a self-hosted serverless runtime in Rust with V8 isolates. The SvelteKit adapter I've built can compile each +server.ts into a standalone mini-worker with per-route isolation and independent scaling.

To build a proper RequestEvent in these mini-workers, I need access to:

• Cookie handling (get_cookies, add_cookies_to_headers)
• Route parsing (parse_route_id, exec)

These are currently buried in src/runtime/server/ and src/utils/.

Proposal

Two levels of improvement, from smallest to most ambitious:

1. Expose key utilities as public API (quick win)

Expose cookie handling and route matching as documented, stable imports — something like:

import { getCookies, addCookiesToHeaders } from '@sveltejs/kit/server';
import { parseRouteId, execRouteMatch } from '@sveltejs/kit/routing';

This alone would unblock adapter authors who build per-route handlers.

2. Per-route partial manifests (longer term)

Allow adapters to generate partial manifests per route at build time, containing only the resolved layout chain and minimal rendering context needed for a single page. This would enable per-route isolation for +page.server.ts too, not just +server.ts.

Why this matters

Any serverless runtime with its own routing could benefit. Instead of routing everything through a single fat worker containing the entire app, each route becomes its own deployment unit with minimal cold start and a tiny bundle size.

Currently OpenWorkers can do this for API routes (+server.ts) but not for pages, and relies on fragile internal imports to do even that.

Happy to help prototype or test any of this!

[gterras]

Hi, you should make this a feature request for better visibility, I don't see maintainers reacting here often.

[teemingc]

Haven’t looked into this, but what’s the difference between this approach and what we’re currently doing for split functions in the Vercel and Netlify adapters?

[max-lt]

Great question. I actually hadn't looked at the Vercel and Netlify split implementations before.

The Netlify approach is quite close to what I'd like to achieve long-term: each function is a thin .mjs wrapper (~1.4 KB) with an inline filtered manifest containing only its route, importing a shared serverless.js + server/. That's a smart architecture, and it partially answers my own Level 2 proposal since per-route partial manifests already exist internally.

That said, even with Netlify's approach, each function still loads the full SvelteKit Server at runtime (~120 KB index.js + dependencies), and the shared serverless.js pulls in node:fs, node:stream, node:buffer, node:crypto, node:process. The total per-worker footprint is still close to 1 MB, and it's tied to a Node.js runtime.

Vercel's approach is heavier: each .func directory is a self-contained copy with its own node_modules, at ~500 KB per function (18 MB total for 32 routes).

What OpenWorkers does differently is the opposite direction: instead of starting from the full Server and filtering down, we start from nothing and only add what each endpoint actually needs. Build-time static analysis detects whether each +server.ts uses cookies, params, locals, or hooks, and only includes that code. An endpoint that doesn't use cookies won't bundle cookie handling at all.

I ran all three on httpbin, a SvelteKit app with 32 API routes:

	Vercel split	Netlify split	OpenWorkers functions
Per function	500 KB (self-contained)	~1.4 KB wrapper + ~1 MB shared	2.5 – 14 KB (standalone)
All 32 functions	18 MB	~1.3 MB (256K wrappers + ~1MB shared)	192 KB
Runtime	Full SvelteKit Server	Full SvelteKit Server	Direct handler, no Server
Node.js required	Yes	Yes (node:fs, crypto, stream...)	No (WebAPI / WinterCG only)

The tradeoff is that this lightweight approach currently only works for +server.ts (API routes), not pages, and it requires access to SvelteKit internals (cookie.js, routing.js) to construct the RequestEvent without Server.

That's the core of my proposal: the official adapters don't need these internals because they delegate to Server which encapsulates everything. Building truly isolated lightweight workers for a non-Node runtime requires going below that abstraction, and right now that means aliasing undocumented internal paths that could break on any release.

[teemingc]

I wonder if this can be solved with better treeshaking for server code on our side in addition to the Vite environment API. We're looking to start work on Kit 3 soon and this might be something easier to approach after the fact.

[teemingc]

There may be similar existing issues tagged with the "large" tag that you may resonate with. One that I can recall recently is #13282 . I think we definitely want more flexible building options for adapters to achieve things like this.

[max-lt]

Tree-shaking would help, but the core challenge for non-Node runtimes is that the Server class is a monolithic abstraction (~120 KB) designed to handle everything: routing, rendering, cookies, hooks, error handling. Even if tree-shaking improves, an adapter that only needs to serve a single +server.ts endpoint still has to instantiate the full Server to get a proper RequestEvent.

In the OpenWorkers adapter, I've tackled this from the adapter side. At build time, I run static analysis on each +server.ts to detect what it actually uses (cookies, locals, params, hooks) and inject only what's needed via build-time defines:

define: {
  WITH_COOKIES: JSON.stringify(usesCookies),
  WITH_PARAMS: JSON.stringify(hasParams),
  WITH_HOOKS: JSON.stringify(withHooks),
}

Combined with esbuild tree-shaking, this produces standalone workers of 2.5–14 KB per route, with zero dependency on Server.

It works, but every adapter author who wants lightweight per-route output would have to reimplement this detection logic. The more natural place for it is in the manifest itself. If builder.generateManifest() (or a new per-route variant) included usage metadata, something like:

{
  id: '/api/users/[id]',
  uses: { cookies: true, locals: false, params: true, hooks: false }
}