SvelteKit Is Quietly Telling You svelte.config.js Is Going Away. Read the Deprecation Trail Before Kit 3 Breaks Your Build.
The July 2026 "What's new in Svelte" post reads like a normal month of quality-of-life work. Remote function commands can now take File objects directly, so you can upload a file without hand-wrapping it in FormData. Remote queries can refresh other queries, which makes invalidating related data after a mutation less of a chore. Prerendered .md and .mdx files get precompressed alongside your HTML, JS, and CSS. Nice, incremental, unglamorous.
Buried in the same list are two items that aren't quality-of-life at all. They're previews of breaking changes coming in SvelteKit 3, dressed up as features. If you're the entire engineering team on a shipping Svelte product, those two are the only items on the page that should change what you do this month.
The two items that actually matter
The first: SvelteKit now lets you pass config directly to the Vite plugin, instead of keeping it in a separate svelte.config.js. The release frames this as a preview of how Kit 3 will want config to live in vite.config.js. Read plainly, that's the project telling you the config file you've been editing for years is on a path to being relocated.
The second: experimental explicit environment variables let you declare and type your env vars in one place, described as a preview of how $env/* will work in SvelteKit 3. Anyone who reaches into $env/static/private or $env/dynamic/public across their app is looking at the early shape of a change to how that whole system behaves.
Neither of these breaks anything today. Both are opt-in previews. That's exactly what makes them easy to skim past, and exactly why they're worth stopping on. A framework that ships a "preview of how X will work in the next major" is doing you a favor: it's showing you the migration months before it's mandatory. The mistake is treating that as trivia instead of a calendar entry.
Why the boring items beat the shiny ones
The File-in-remote-commands and query-refresh improvements are the ones that'll get the blog headlines, and they're genuinely useful if you're mid-build. But they're additive. Nothing you have breaks because they exist; you adopt them when you happen to touch that code.
Config location and $env behavior are different in kind, because they're structural. When a major version changes where config lives or how environment variables resolve, it can touch every build, every deployment, and your CI in ways a new convenience method never will. The blast radius is the whole project, not one function. That's the general rule worth internalizing: in any release note, the additive features are optional and the structural previews are homework. The shiny thing is a toy; the boring deprecation is the one that can ruin a Saturday.
The discipline: read the trail, don't chase it
I've watched solo devs handle framework majors two ways. One group upgrades the day the new version drops, hits the breaking change cold, and loses a weekend firefighting a production build while customers watch. The other group read the deprecation trail while it was still a preview, knew their exposure, and did the migration as a planned two-hour job on a quiet afternoon. Same change, wildly different cost. The only difference was whether they treated the preview as a signal.
So the move here isn't to migrate to vite.config.js today. Previews change before they land, and pre-migrating against an experimental API is how you do the work twice. The move is to measure your exposure now, while it's cheap, so that when Kit 3 ships you already know the size of the job.
Concretely, spend twenty minutes and answer three questions. First, what's actually in your svelte.config.js? Is it a thin file with an adapter and a couple of options, or have you accumulated preprocessors, aliases, and custom config that'll all need to move? Second, how many places in your app read from $env/*, and are they centralized or scattered across dozens of files? Third, given both answers, is a forced migration a half-hour rename or a real refactor? Write the answer down somewhere you'll see it when Kit 3 lands. That note is the entire payoff.
What I'd actually do
If your svelte.config.js is thin and your env access is centralized, you're fine: do nothing, and migrate in an afternoon when the stable path exists. If either is sprawling, that's useful to know now, because it means the Kit 3 upgrade is a project to schedule rather than a patch to apply, and you'd rather learn that from a July preview than from a red CI pipeline in the fall.
For the additive stuff (File in remote commands, query refresh, precompressed markdown) just adopt it as you go. There's no strategy required; it's free improvement the next time you're in that code. Save your planning energy for the structural changes, because those are the only ones that get more expensive the longer you ignore them.
The honest take
I could be wrong about the timeline. "Preview of how it'll work in the next major" is not a shipped, frozen API, and the Svelte team has walked back or reshaped experimental directions before, so don't treat these previews as a contract, and definitely don't rebuild your config against them yet. It's also fair to say that for a small, simple SvelteKit site, none of this will ever be more than a quick find-and-replace, and worrying about it is overkill.
But the habit generalizes past Svelte, and that's the real point. Every framework you depend on buries its most important news in the least exciting bullet points. The new toy is marketing; the quiet deprecation is the thing that decides whether your next upgrade is a scheduled afternoon or an emergency. Reading release notes for the deprecations instead of the features is a boring skill, and it's one of the highest-leverage habits a solo dev can build. SvelteKit just handed you a clean chance to practice it.
Author
Lukas
@lukcombinator