SvelteKit config in vite.config, explicit env vars and new declaration tag support across the toolchain

This month brought a real shift in how SvelteKit projects are configured. You can now define your SvelteKit config directly inside vite.config.js and skip svelte.config.js entirely. We also got the first preview of explicit environment variables, which will eventually replace $env/* modules in SvelteKit 3.

On top of that, the language tools and the sv CLI both caught up with Svelte's new {const ...} declaration tags, so the whole toolchain is now in sync.

Let's dive in!

What's new in SvelteKit permalink

What's new in SvelteKit

• You can now pass your SvelteKit config directly to the Vite plugin, so a separate svelte.config.js is no longer required, as a preview of how Kit 3 will require config to live in vite.config.js (2.62.0, Docs, #15944)
• Experimental explicit environment variables let you declare and type your env vars in one place, as a preview of how $env/* will work in SvelteKit 3 (2.63.0, Docs, #15934)
• Remote function commands can now receive File objects directly, so you can upload files without manually wrapping them in FormData (2.64.0, Docs, #15978)
• Remote queries can now refresh other queries, making it easier to invalidate related data after a mutation (2.65.0, Docs, #16012)
• Prerendered .md and .mdx files are now precompressed alongside HTML, JS and CSS for faster delivery (2.66.0, Docs, #15893)
• SvelteKit now warns when boolean fields in remote form schemas are not marked optional, which is a common cause of silent submit failures (2.66.0, Docs, #15804)
• The new prerender.handleInvalidUrl option lets you customize how invalid URLs found during crawling are reported (2.67.0, Docs, #16088)
• RemoteFormEnhanceInstance and RemoteFormEnhanceCallback are now exported types, so you can type your custom enhance callbacks directly (2.68.0, Docs, #15816)
• Submitted submit fields now keep their value in the form action payload, which makes multi-button forms easier to handle on the server (2.68.0, Docs, #15979)

For all the features and bugfixes that landed this month, check out the SvelteKit / Adapter CHANGELOGs.

What's new in the Svelte CLI and Language Tools permalink

What's new in the Svelte CLI and Language Tools

• The Svelte CLI demo template now uses the new {const ...} declaration tag, so newly created projects show off the latest Svelte syntax ([email protected], #1110)
• sv create now scaffolds projects against @sveltejs/kit ^2.62.0 and moves the Svelte config into the Vite plugin by default ([email protected], #1119)
• A new experimental add-on lets you toggle experimental flags and opt into @next versions directly from the CLI ([email protected], #1121)
• The drizzle and better-auth add-ons now support SvelteKit's new explicit environment variables ([email protected], #1122)
• New defineEnv and svelteConfig helpers in @sveltejs/sv-utils make it easier to read and edit a project's Svelte config from add-ons ([email protected])
• The Svelte language server, svelte-check, and svelte2tsx now understand Svelte 5's {const ...} declaration tags ([email protected]/[email protected]/[email protected], #3033)
• CSS completions now work inside nested

Patch Changes

• fix: error at compile time on duplicate snippet/declaration tag definitions (#18351)
• fix: parse declaration tag contents more robustly (#18353)
• fix: correctly transform references to earlier declarators in a declaration tag (e.g. {let a = $state(0), b = $derived(a * 2)}) (#18348)
• fix: avoid spurious state_referenced_locally warnings for $derived declarations in declaration tags (#18348)
• fix: tolerate whitespace before let/const in declaration tags (#18348)
• fix: prevent infinite loop when a tag's expression ends with a trailing / at the end of the input (#18350)
• fix: more robust parsing of declaration tags with regards to type (#18330)
• fix: preserve newlines in spread input values when the type attribute is applied after value (#18345)
• fix: update SvelteURLSearchParams when setting duplicate keys to the same joined value (#18336)
• fix: check references for blockers on server, too (#18352)

Patch Changes

• fix: unlink errored and otherwise finished batch (#18264)
• perf: walk composedPath() directly in delegated event propagation (#18268)
• fix: transfer effects when merging batches (#18254)
• fix: allow $derived(await ...) in disconnected effect roots (#18273)
• fix: remove temporary raw-text hydration markers (#18269)
• fix: propagate async @const blockers through closure references so template expressions like {(() => host)()} correctly wait for the awaited value (#18309)
• fix: properly unlink batches (#18298)
• fix: settle discarded batch (#18290)
• fix: declare let: directives before {@const} declarations on slotted elements (#18271)
• fix: resume outro-ed branches if they were kept around (#18291)
• fix: avoid waterfall-warning when async resolves to same value (#18297)
• fix: correctly coordinate component-level effects inside async blocks (#18260)
• fix: make unnecessary commit work less likely (#18263)
• chore: add tag name to a11y_click_events_have_key_events warning (#18272)
• fix: catch rejected promises while merging/committing (#18266)

Patch Changes

• fix: leave stale promises to wait for a later resolution, instead of rejecting (#18180)
• fix: keep dependencies of $state.eager/pending (#18218)
• fix: reapply context after transforming error during SSR (#18099)
• fix: don't rebase just-created batches (#18117)
• chore: allow null for pending in typings (#18201)
• fix: flush eager effects in production (#18107)
• fix: rethrow error of failed iterable after calling return() (#18169)
• fix: account for proxified instance when updating bind:this (#18147)
• fix: ensure scheduled batch is flushed if not obsolete (#18131)
• fix: resolve stale deriveds with latest value (#18167)
• chore: remove unnecessary increment_pending calls (#18183)
• fix: correctly compile component member expressions for SSR (#18192)
• fix: reset source.updated stack traces after flush (#18196)
• fix: replacing async 'blocking' strategy with 'merging' (#18205)
• fix: allow @debug tags to reference awaited variables (#18138)
• fix: re-run fallback props if dependencies update (#18146)
• fix: abort running obsolete async branches (#18118)
• fix: ignore comments when reading CSS values (#18153)
• fix: wrap Promise.all in save during SSR (#18178)
• fix: ignore false-positive errors of $inspect dependencies (#18106)

We’ve released patches for 5 vulnerabilities across devalue, svelte, @sveltejs/kit, and @sveltejs/adapter-node. Here’s what you need to know:

Upgrade now

If you’re using any of these packages, upgrade them to their corresponding non-vulnerable versions:

• devalue: 5.6.2
• svelte: 5.46.4
• @sveltejs/kit: 2.49.5
• @sveltejs/adapter-node: 5.5.1

For cross-dependent packages — svelte and @sveltejs/kit depend on devalue — patched versions already include upgraded dependencies.

Commentary

We’re extremely thankful to all of the security researchers who responsibly disclosed these vulnerabilities and worked with us to get them fixed, to the security team at Vercel who helped us navigate the disclosure process, and to the maintainers who worked to publish the fixes.

Over the last few weeks, we've seen a spate of high profile vulnerabilities affecting popular tools across the web development ecosystem. While they are unfortunate, it has been encouraging to see the community pulling together to keep end users safe. Using the lessons learned from these vulnerabilities, we will invest in processes that will help catch future bugs during the writing and review phases, before they go live.

If you think you have discovered a vulnerability in a package maintained by the Svelte team, we urge you to privately report it via the Security tab on the repo in question (or the Svelte repo, if unsure).

Details

Full reports are available in the published security advisories, but we’ve included a brief summary of each below.

CVE-2026-22775: DoS in devalue.parse due to memory/CPU exhaustion

• Packages affected: devalue
• You’re affected if:
  • You’re using devalue versions 5.1.0 through 5.6.1, and
  • You’re parsing user-controlled input
• Effects:
  • A malicious payload can cause arbitrarily large memory allocation, potentially crashing the process
  • SvelteKit applications using remote functions are vulnerable, as the parameters are run through devalue.parse
  • If you don’t have remote functions enabled, SvelteKit is not vulnerable

CVE-2026-22774: DoS in devalue.parse due to memory exhaustion

(Yes, this is very similar to the previous CVE. No, it is not the same!)

• Packages affected: devalue
• You’re affected if:
  • You’re using devalue versions 5.3.0 through 5.6.1, and
  • You’re parsing user-controlled input
• Effects:
  • A malicious payload can cause arbitrarily large memory allocation, potentially crashing the process
  • SvelteKit applications using remote functions are vulnerable, as the parameters are run through devalue.parse
  • If you don’t have remote functions enabled, SvelteKit is not vulnerable

CVE-2026-22803: Memory amplification DoS in Remote Functions binary form deserializer

• Packages affected: @sveltejs/kit
• You’re affected if:
  • You’re using SvelteKit versions 2.49.0 through 2.49.4, and
  • You’ve enabled the experimental.remoteFunctions flag, and
  • You’re using form
• Effects:
  • Users can submit a malicious request that causes your application to hang and allocate arbitrarily-large amounts of memory

CVE-2025-67647: Denial of service and possible SSRF when using prerendering

• Packages affected: @sveltejs/kit, @sveltejs/adapter-node
• You’re vulnerable to DoS if:
  • You’re using @sveltejs/kit versions 2.44.0 through 2.49.4, and
  • Your app has at least one prerendered route
• You’re vulnerable to DoS and SSRF if:
  • You’ve using @sveltejs/kit versions 2.19.0 through 2.49.4, and
  • Your app has at least one prerendered route, and
  • You’re using @sveltejs/adapter-node without a configured ORIGIN environment variable, and you are not using a reverse proxy that implements Host header validation
• Effects:
  • DoS causes the server process to die
  • SSRF allows access to internal resources that can be reached without authentication from SvelteKit’s server runtime
  • If the stars align, it’s possible to obtain SXSS via cache poisoning by forcing a potential CDN to cache an XSS returned by the attacker's server (the latter being able to specify the cache-control of their choice)

CVE-2025-15265: XSS via hydratable

• Packages affected: svelte
• You’re vulnerable if:
  • You’re using svelte versions 5.46.0 through 5.46.3, and
  • You’re using hydratable, and you’re passing unsanitized, user-controlled strings in as keys
• Effects:
  • Your users are vulnerable to XSS if an attacker can manage to get a controlled key into hydratable that is then returned to another user

SvelteKit apps can now emit OpenTelemetry traces and reliably set up observability instrumentation using instrumentation.server.ts

Understanding how your SvelteKit application behaves in production — from request flows to performance bottlenecks — is crucial for building reliable user experiences. SvelteKit now has first-class support for observability: built-in OpenTelemetry tracing, and a dedicated instrumentation setup file that ensures your monitoring tools work seamlessly.

To opt in, upgrade SvelteKit and your adapter and add the following to your svelte.config.js:

export default {
  kit: {
    experimental: {
      tracing: {
        server: true
      },
      instrumentation: {
        server: true
      }
    }
  }
};

First-party OpenTelemetry traces

SvelteKit can now emit OpenTelemetry traces for the following:

• handle hook (handle functions running in a sequence will show up as children of each other and the root handle hook)
• load functions (includes universal load functions when they run on the server)
• Form actions
• Remote functions

The emitted spans include attributes describing the current request, such as http.route, and surrounding context, such as the +page or +layout file associated with a load function. If there are additional attributes you think might be useful, please file an issue on the SvelteKit GitHub issue tracker.

A convenient home for all of your instrumentation

Emitting traces alone is not enough: You also need to collect them and send them somewhere. Under normal circumstances, this can be a bit challenging. Because of the nature of observability instrumentation, it needs to be loaded prior to loading any of the code from your app. To aid in this, SvelteKit now supports a src/instrumentation.server.ts file which, assuming your adapter supports it, is guaranteed to be loaded prior to your application code.

In Node, your instrumentation might look something like this:

import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-proto';
import { createAddHookMessageChannel } from 'import-in-the-middle';
import { register } from 'module';

const { registerOptions } = createAddHookMessageChannel();
register('import-in-the-middle/hook.mjs', import.meta.url, registerOptions);

const sdk = new NodeSDK({
  serviceName: 'my-sveltekit-app',
  traceExporter: new OTLPTraceExporter(),
  instrumentations: [getNodeAutoInstrumentations()]
});

sdk.start();

If you're deploying to Vercel, it would look something like this:

import { registerOTel } from '@vercel/otel';

registerOTel({
  serviceName: 'my-sveltekit-app'
});

Consult your platform's documentation for specific instrumentation instructions. As of now, all of the official SvelteKit adapters with a server component (sorry, adapter-static) support instrumentation.server.ts.

Acknowledgements

A huge thank-you to Lukas Stracke, who kicked us off on this adventure with his excellent talk at Svelte Summit 2025 and his initial draft PR for instrumentation.server.ts. Another thank-you to Sentry for allowing him to spend his working hours reviewing and testing our work.

Twenty-four days, twenty-four features

Last December, Svelte Society presented an advent calendar's worth of festive Svelte-themed code challenges.

This year, we're turning it around: you get to relax while we take on a challenge. We've set ourselves a goal of releasing one thing a day from here until Christmas, whether it's a new feature in Svelte or SvelteKit or an improvement to the website.

Follow @svelte.dev and @sveltesociety.dev and check back every day to see what we've been cooking up.

Day 1: error boundaries

This is a long-awaited and much-requested feature, that allows you to isolate and recover from errors that occur during rendering.

Day 2: each without as

If you just want to render something in an {#each ...} block n times, and don't care about the value, you can now omit the as part.

Day 3: exported snippets

You can now export snippets from a component's

Tailwind, auth, databases and more — just an npx sv away

We’ve just released sv, a new Command Line Interface (CLI) for creating, enhancing, and upgrading Svelte projects.

One of the most common question we hear is "how do I set up Tailwind on my new project?". Tailwind has SvelteKit documentation, but it lists eight steps. While the community-led svelte-add project could automate the process, few knew about it.

Introducing sv at Svelte Summit Fall 2024

Now, we're offering that functionality via our own CLI, directly within the project creation screen. And not just for Tailwind — we have built-in add-ons for formatting, linting, testing, setting up databases and auth and i18n and more. Just run npx sv create and follow the prompts:

$ npx sv create

┌  Welcome to the Svelte CLI! (v0.5.8)
│
◇  Where would you like your project to be created?
│  my-new-app
│
◇  Which template would you like?
│  SvelteKit minimal
│
◇  Add type checking with Typescript?
│  Yes, using Typescript syntax
│
◆  Project created
│
◆  What would you like to add to your project? (use arrow keys / space bar)
│  ◻ prettier (https://prettier.io)
│  ◻ eslint
│  ◻ vitest
│  ◻ playwright
│  ◻ tailwindcss
│  ◻ drizzle
│  ◻ lucia
│  ◻ mdsvex
│  ◻ paraglide
│  ◻ storybook
└

You can also run npx sv add to apply add-ons to existing projects. In the near future, we will also be supporting add-ons contributed by the community within sv. If you’re interested in building one, please subscribe to the issue in the CLI repository to be notified when third party add-ons are supported.

It doesn't stop there. Over time, Svelte has accumulated a handful of CLIs: svelte-check type-checks your project from the command line, npx svelte-migrate helps you upgrade to new major versions, and in the future we might have even more capabilities. Remembering the package name of each tool is cumbersome, which is why we unify the experience under one roof, sv. That means you can now run sv migrate svelte-5 to upgrade your Svelte 4 projects to Svelte 5. (The migration functionality can also be found in Svelte for VS Code as well as in the playground.)

A huge thank you to Christopher Brown (chbrown) who donated the sv package name on npm to make this CLI possible. This package merges the previous create-svelte and community-led svelte-add tools into a single package. Thank you to Manuel (manuel3108) and Adrian (CokaKoala) who recently took over maintenance of the svelte-add project and have joined as the newest Svelte maintainers in making this project an official part of Svelte. Also thank you to J (babichjacob) for creating the svelte-add project and successfully stewarding it for years as an important part of the Svelte community.

To see the CLI in action, check out this demo from Ben Davis and t3.gg...

Introducing sv at Svelte Summit Fall 2024

...or run npx sv to try it out yourself.