SvelteKit asks you to reproduce your build bug without SvelteKit

The repository description points at Vite before anything else

The description field for this repository is not a feature summary. It says web development, streamlined, and then adds that many issues related to how a project builds originate from Vite, which is used to build a SvelteKit project.

That sentence is repeated in effect by the bug reporting policy. Before filing, you are asked to make sure the issue involves SvelteKit, and if an issue originates from Vite you are asked to report it in the Vite issue tracker.

The consequence is a division of labour you inherit. SvelteKit owns the framework layer, routes, adapters, and the kit packages; Vite owns dev server behaviour, bundling, and the plugin pipeline a SvelteKit project runs through. A large share of what looks like a framework bug lands in the second category, and filing it in the first means it gets closed and redirected rather than fixed. Knowing which side owns a failure before you spend an afternoon reproducing it is the difference between a useful report and a bounced one.

Reproduce it with npm create vite, not with your app

The reproduction instructions are specific, and they deliberately leave SvelteKit out. For a client-side only repro you create a new Vite project with `npm create vite@latest`. For SSR or library repros you use `npm create vite-extra@latest`.

The reason follows from the policy above. If the failure can be shown in a project that has no SvelteKit in it, the bug is not in SvelteKit, and the correct home for it is the Vite tracker where the maintainers of that layer will see it.

For the maintainer this is a gift, because a twenty line project that misbehaves is worth more than a real application with a hundred moving parts. For you it is a cost, because the minimal repro will not resemble the project you actually maintain, so you maintain the reproduction separately and keep both. Expect to do this work before you know whether your issue is even in the right tracker.

The default branch is named version-3, and 3.0.0 just shipped

The repository default branch is called version-3, which is unusual enough to notice before you clone anything. The recent releases line up with it: @sveltejs/[email protected], @sveltejs/[email protected] and @sveltejs/[email protected] were all published on October 29, 2026. The last push to the repository was on November 2, 2026.

So the source of truth you get by default is a major version line, not a rolling trunk, and the tags at that line have reached 3.1.1.

The consequence is about what you are reading. A clone gives you the code for the current major under development, so behaviour you read about on the default branch is the behaviour of 3.x, not of whatever version you have installed. And because the line lives on a version branch rather than only in tags, the moment to read it is when you are moving to 3.0 rather than while you are deciding whether to. Check the version branch for the major you are on before drawing conclusions about an upgrade.

Nine packages ship from one tree, and the versions move independently

The README is a package table, and it lists nine of them with a path and a changelog link for each: @sveltejs/kit itself, then @sveltejs/adapter-auto, adapter-cloudflare, adapter-netlify, adapter-node, adapter-static, and adapter-vercel, plus @sveltejs/enhanced-img and @sveltejs/package.

Seven of the nine are kit plus adapters, which is the shape of the deployment story. Your application code does not change between hosts; the adapter does, and the adapter is what turns a built project into something a particular platform runs. So a behaviour difference between two deployments is an adapter question before it is a kit question.

The same-day releases make the independence visible: kit was at 3.1.1, package at 3.0.2 and adapter-vercel at 7.0.2. They share a repository and a release moment, not a version number, so a project with three @sveltejs dependencies in its manifest is holding three version lines that can drift apart. Read the changelog of the adapter you deploy with, not only the one for kit.

The adapters you did not get from this project are community maintained

Alongside the six official adapters, the README points at additional adapters maintained by the community, listed on the Svelte Society package directory under the SvelteKit adapters category.

That single line is the whole difference between an official adapter and one that is not, and it is a meaningful one. An official adapter is versioned in this repository, and has a changelog here. A community adapter is somebody else's release with their own compatibility story.

The consequence lands at deploy time. If your host is only supported by a community adapter, then whether that adapter works with the kit version you just upgraded to is not something this README will tell you, and a mismatch surfaces as a build or runtime error on that host rather than in your app. Pin the adapter, read its own changelog around your upgrade dates, and if you can choose between hosts, prefer the one with an adapter released from this repository.

Donations here pay for hosting, and only then for development

The funding note is about Svelte rather than about SvelteKit, which is itself a useful signal about where the effort sits. Svelte is described as an MIT-licensed open source project with its ongoing development made possible entirely by volunteers, and readers are pointed at becoming a backer on Open Collective.

The use of money is spelled out with unusual precision. Funds donated via Open Collective will be used for compensating expenses related to Svelte's development such as hosting costs. If sufficient donations are received, funds may also be used to support Svelte's development more directly.

Read that ordering as a constraint on expectations. The primary line item is infrastructure, direct engineering support is conditional on donations being sufficient, and the whole mechanism is volunteer-run. So a well-reproduced bug and a focused patch are the currency that gets attention fastest, and a broad feature request competes against that, especially since this repository's README does not even attempt to describe the roadmap. The documentation site at svelte.dev/docs/kit is where the guidance lives.

The README is a map, not a manual

It is worth being blunt about what this repository's README contains. A heading, a sentence about streamlined web development, a link to the documentation at svelte.dev/docs/kit, the package table, the Vite bug reporting policy, a link to CONTRIBUTING.md for developing locally, the Svelte funding note, and the MIT license.

There is no explanation of routing, no list of configuration files, no explanation of what an adapter does, and no description of the development server. That absence is not a defect in the writing, it is a division of responsibility: this is the monorepo where the code and the changelogs live, and svelte.dev/docs/kit is the manual.

The consequence for anyone evaluating the framework is that the repository tells you how the project is organised and where the boundaries with Vite are, and nothing about how to use it. If you are choosing between frameworks on the strength of a README, this one will tell you almost nothing, which is a fair signal in itself.

Each package is a directory with its own changelog, so bumps are coordinated

Every row in the package table points at a path in this repository, packages/kit, packages/adapter-node, packages/enhanced-img, and so on, with a CHANGELOG.md inside each one. There is no separate repository per package.

That has a direct consequence for how releases work. A kit major and an adapter patch are cut from the same tree, which is why the adapter and the framework can be expected to agree on what changed, and why reading a single adapter's changelog tells you what that adapter does about a new kit release.

The risk is the mirror image. Because they are versioned independently inside one tree, a manifest that mixes a current kit with an older adapter is a combination nobody published as a set. There is no compatibility matrix in this README to check it against, so when you upgrade, upgrade kit and the adapter you deploy with in the same change, and use each package's own changelog as the record of what that package now expects.

Editorial conclusion

SvelteKit fits a team that wants one codebase with a real server-side story and a per-host deployment adapter, and it is a poor fit for anyone who wants a self-contained build toolchain, since the build layer belongs to Vite and most of that surface is somebody else's issue tracker. Before you commit, check which adapter your host uses and whether it is official or community maintained, read that adapter's changelog rather than only the kit changelog, and file build problems where the project asks, because a SvelteKit report about a Vite failure will be moved.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes