The SvelteKit Roadmap

The SvelteKit roadmap is split up between a few resources, however the main reference we have is the GitHub Milestones page. This is a list of issues and feature requests largely contributed by the community.

By following the tags and discussions, there’s some indication of what’s coming sooner rather than later. And by the discussions and upvotes, we can get a fair idea of what’s popular within the community.

So in this article, we’ll discuss what lies ahead for SvelteKit, and talk about some of the most exciting features we may get to see before, and with v3.

Skip to FAQ’s

The Priority Important Category

This is the group of features and bugs labeled as p1-important (priority 1), which is at the top of the priorities list. The label set by the team defines it as:

SvelteKit cannot be used by a large number of people, basic functionality is missing, etc.

These are the issues the SvelteKit team is actively looking to incorporate. With these issues, the question is more ”when will it be included?” rather than ”if it will be?“.

via GIPHY

In this section we’ll go through the more prominant features up ahead. The issues here that won’t be covered are either bug fixes, or features with very simple workarounds specified in the linked discussion.

The features we’ll talk about are:

1. Native Support for Websockets in Svelte
2. Language Translations and i18n, and
3. Provide Access to History State

You can see the full list of top-priority features here.

Native Support for Websockets in Svelte

This one is extremeley popular, and many devs in the community were hoping for it to be announced with the release of version 2. Whilst we got shallow routing, we didn’t get websockets, despite the fact that it’s been on the cards since mid-2021 - well before even SvelteKit 1.0 was released.

To add to injury, it seems as though websockets won’t get a look in until at least after the Svelte 5 release. Here’s what SvelteKit maintainer Ben McCann has said:

The core team won’t be implementing this in the near future as we’re currently focused on a very exciting set of changes in Svelte 5… Source

via GIPHY

But he also mentioned that they’ll still be reviewing pull requests in the meantime in case the community is willing to have a crack at it.

In the meantime

Whilst we wait for websockets to be natively built into SvelteKit, there are a few workarounds which were noted in the same thread.

The solution that received the most attention and is likely the most used for SvelteKit at the moment, is using the Node Adapter with Socket.io.

How to set up websockets in SvelteKit

1. First install the Node Adapter package:

npm i -D @sveltejs/adapter-node

2. Install the Socket.io server and client:

npm install socket.io socket.io-client

3. Modify your vite.config.ts file to add in the adapter-node package

import { Server } from 'socket.io';
import { type ViteDevServer, defineConfig } from 'vite';

const webSocketServer = {
	name: 'websocket',
	configureServer(server: ViteDevServer) {
		if (!server.httpServer) return;

		const io = new Server(server.httpServer);

		io.on('connection', (connection) => {
			connection.emit('eventFromServer', '✅ Connected');
		});
	}
};

export default defineConfig({
	plugins: [sveltekit(), webSocketServer]
});

4. The use it from your Svelte components:

<script lang="ts">
	import { io } from 'socket.io-client';

	const websocket = io();

	websocket.on('eventFromServer', (message) => {
		console.log(message); // will log '✅ Connected';
	});

	let currentMessage: string = '';
	$: currentMessage, websocket.emit('eventFromClient', currentMessage);
</script>

<input bind:value={currentMessage} />

So in this example, when we mount the component (or page) and connect to the websocket, we log ✅ Connected on the client, and then whenever currentMessage changes from the input, it will also be sent to the server.

An example like this would be used if you had 2 people connected to a server ‘room’, where both people could see the current message the other person was typing, before they sent it.

via GIPHY

Now let’s look at another major feature the SvelteKit team are working on; support for i18n.

Language Translations and i18n

For quite some time, the Svelte team have been looking into how to best make the decision of providing translation and i18n support out of the box for SvelteKit apps.

Between the i18n brainstorming and Translations GitHub issues, it’s likely we’ll get some opinionated approach to this before SvelteKit v3.

SvelteKit 2.3.0 introduced the reroute hook, which allows you to edit a URL before SvelteKit uses it to render a route - even whilst showing the origin URL to the user.

The reroute hooks runs before handle and checks the requested url against a translated object in order to serve the correct page with the assumed translation.

You could implement it like this:

src/hooks.server.ts

import type { Reroute } from '@sveltejs/kit';

const translated: Record<string, string> = {
	'/en/about': '/en/about',
	'/de/ueber-uns': '/de/about',
	'/fr/a-propos': '/fr/about'
};

export const reroute: Reroute = ({ url }) => {
	if (url.pathname in translated) {
		return translated[url.pathname];
	}
};

So if the user requested /de/ueber-uns, it would resolve the page /de/about, which would be your regular src/routes/about page, with the German language. You would however, be required to implement the translations on your own accord, or use a library like Banana i18n.

via GIPHY

The only problem with this reroute as it currently stands is that you would have content in 2 places, for example:

1. https://sveltekit.io/about, and
2. https://sveltekit.io/en/about

So you would typically redirect the latter (with ‘en’) to the former (without ‘en’). This can have repercussions for SEO, and there’s obviously a better way. That’s why in the reroute enhancements GitHub issue, there’s discussion as to how to best make modifications to reroute. And interestingly, it’s currently set to be addressed in SvelteKit 3.

Sorting out first class i18n is the primary feature focus for the SvelteKit team post-2.0 release. There’s still work to be done and decisions to be made by the team, but they are obviously keen to hear as much as possible from the community on this issue.

Provide Access to History State

Most of the discussion on this topic was resolved by the shallow routing feature released with SvelteKit v2. The pushState and replaceState functions were implemented to have more control over history entries in the user’s browser. And beyond that, pop-up views were implemented for rendering other page’s data inside of the current page.

The only thing that needs to be developed on this issue is manipulating the state in beforeNavigate.

For complex apps with many state variables, it can be important to do something before navigating - like making sure they wish to navigate, or telling them what’s about to happen (e.g. a dialog saying that the modal will close and their page state will vanish).

So it’s likely that we’ll receive some optional additional parameter in the pushState and replaceState functions to address this.

via GIPHY

The full list of top priority features for SvelteKit

If you want to look at all of the upcoming priority features, you can read the discussions:

1. Native support for web sockets
2. i18n brainstorming
3. Translations
4. Shim SvelteKit runtime import aliases / Importing $app/* fails
5. Add option to always reinstantiate a component on navigation
6. Provide access to history state
7. Rejecting streamed data
8. CSS file not found error
9. docs: links to types are missing

Expectations for SvelteKit 3

It hasn’t been long since SvelteKit 2 was released, however we already have an insight as to what is targeted for the future release of SvelteKit v3.

The best speculation we have for the release date of SvelteKit v3 is the 14th December 2024. This is purely based on the past pattern of releasing major versions annually on the 14th December.

via GIPHY

The high-level roadmap suggests that the focus is first to bring Svelte 5 to fruition in early 2024, and then shift more towards building out some of the features for SvelteKit 3.

So whilst it’s still a while before any of this gets released, let’s have a look at the current 3.0 task list.

The most exciting topics we’ll go over are:

1. Expanded support for Svelte 5,
2. reroute Enhancements

The details and discussions for these issue are very early-stage and minimal, so we’ll go through some of them in no great detail. As the ideas and methods become more solidified, we’ll amend what we know.

Expanded support for Svelte 5

Svelte 5 is expected to be released in the first quarter of 2024, and after that there’ll be no shortage of features to develop and improve upon.

via GIPHY

So in the official SvelteKit 3 release, the team is in very early discussions of moving the built-in stores to be rune-based.

This means that after Svelte 5, the $app/stores will undergo some API changes, in favor of a Rune character.

reroute Enhancements

We discussed the reroute function in the Language Translations and i18n section, and know that it’s a priority-1 feature for SvelteKit. This issue is interested in removing the requirement for having content in 2 places to handle a standard route (https://sveltekit.io/about) and a language-based route (https://sveltekit.io/en/about)

Given that the improvements for this function are placed in the 3.0 category, it seems as though the team will put an emphasis on this as a primary feature of SvelteKit 3.

The full list of current SvelteKit 3 features

If you want to look at all of the upcoming features assigned to the v3 release, you can read the discussions:

1. Expanded support for Svelte 5
2. use undefined instead of null for empty form prop
3. revisit modulepreload options?
4. reroute enhancements
5. Disclose render mode
6. SvelteKit 3 various breaking changes notes

via GIPHY

Other Features

There are over 100 open issues/tasks sitting rather uncategorized as ‘soon’. This is the high-level umbrella page which also includes all the features mentioned so far.

Many of the ‘soon’ tasks are bug fixes and documentation changes, so we’ll only talk about the upcoming features that may be introduced to SvelteKit over the coming months.

• Generated types for pages/endpoints
• Image Processing
• Sitemaps and programmatically get all routes

Generated Types For Pages and Endpoints

In addition to providing types to Svelte components with our load functions, the team is also looking to add types to:

• goto functions,
• fetch functions, and
• typed links in anchor tags (<a>)

This would allow us to have intellisense when choosing navigation, and build errors to catch invalid navigation instances.

via GIPHY

This will also provide more direction when accessing GET/POST functions in our +server.ts endpoints. This may even resolve the issue raised in the SvelteKit backend article on the issue of typesafe server functions.

The most in depth contribution to the topic was made by SvelteKit contributor ivanhofer in 2021. In the proposal, he offers a method to achieve all this this under the hood, which is too verbose to go into in this article. However, from Vite’s import.meta.glob, we could generate something to this effect:

type Endpoints = {
	GET: ['/', 'products'] | ['/', 'products', '/', id];
	POST: ['/', 'products'];
	PATCH: ['/', 'products', '/', id];
};

And then when accessing the API routes:

fetch('/products');
// @ts-expect-error
fetch('products');
fetch('/products/12345');
fetch('/products', { method: 'POST' });
// @ts-expect-error
fetch('/products', { method: 'PATCH' });
// @ts-expect-error
fetch('/products/12345', { method: 'POST' });
fetch('/products/12345', { method: 'PATCH' });

This is just for fetch calls, however for routes, it’s a similar deal, however less complex. The only issue with this is that it still leaves room for error in the expected body of POST calls, and query params of GET calls.

As there hasn’t been much meaningful movement towards resolving this issue recently, it’s yet to be seen whether this gets implemented before SvelteKit 3. Though a feature like this would be a fantastic addition to a major release.

Image Processing

The image processing feature has been released with the @sveltejs/enhanced-img package. This processes all the local images used in your app, and serves them to the user in a web-based format (.avif or .webp), and serves the correct size to suit their device.

via GIPHY

It’s been released as experimental, as they work to iron out some bugs and collect feedback from the community, however there’s another part of this that would make using the package a whole lot better.

The team are considering extending the functionality to serve dynamic images. As discussed in another GitHub issue, you may be able to use enhanced:img for serving CDN images, or images from a database.

This would address the main pain-point of serving images with the package now, and you could use <enhance:img /> on almost everything!

Sitemaps and programmatically get all routes

SvelteKit’s approach to SEO is self-described as “uncompromising”, so it’s said that they’ll provide some out-of-the-box solution to build sitemaps with ease. The discussion of potential approaches to achieve this can be found in this GitHub issue.

It’s safe to say that in order to achieve sitemap generations, they’ll have to expose some API to get all routes in the project, which is also a topic on the “soon” list.

via GIPHY

Since there’s been no progress from the team with this, community members have published packages to handle sitemap generations, including super-sitemap and svelte-sitemap.

Conclusion

As there will be constant completions, additions and modifications made to the features described in this post, there will be regular updates to reflect the current state.

We have only touched on the big upcoming features in this article, so there’s plenty more smaller and niche features that the big-brains might enjoy getting into the weeds of. As mentioned, you can go through all of the milestones on GitHub, and contribute where possible.

Given that Svelte 5 is around the corner, progress on these milestones may be sluggish for a moment. This should change later in the year leading up to the SvelteKit 3 release.

FAQ’s