The full-stack meta-framework — file-based routing, SSR, deployment adapters. v10r runs SvelteKit 3.1; its config (adapter, version, csp, preprocess) is the sveltekit({...}) call in vite.config.ts — there is no svelte.config.js. See the sveltekit skill for routing and load-function patterns.
The 2 → 3 move, with every behaviour change it forced, is commit 0b080a231 (its message is the record).
Why was it chosen?
- Adapter system enables platform-agnostic builds — the project deploys to Vercel but can swap to Node/Bun via config.
- Rendering mode is per-route (SSR default, SSG, CSR), matching the showcase-as-documentation architecture.
Architecture features the project relies on:
src/lib/server/**and*.server.tsare blocked from client imports at build time, whether reached through#lib/server/or a relative path — the load-bearing boundary for the multi-client core (seedocs/codebase-organization.md).- Node subpath imports (
#lib/*,#patterns/*in package.jsonimports) replace the$libalias, so app code, Vitest and bare-Bun scripts resolve the same specifiers. Specifiers carry the real extension (#lib/server/db/index.ts): Bun does not map.jsto.tsthrough package imports. - Route groups
(name)organize routes without affecting URLs.
Known limitations
- Vite-only bundler; cold dev start is slow on large projects.
- Bun adapter:
svelte-adapter-bunis community-maintained; ORIGIN-header handling breaks form CSRF. Fallback isadapter-nodevia a single config change.
Related
- svelte.md - UI framework
- bun.md - Runtime
- ../ops/deployment.md - Deployment adapters