I've made a small demo, of how we use routes in wild life:
https://github.com/nosovk/svelte-kit-multiple-routes-example

check .env file in a repo and svelte-config.js to get an idea.

In real life projects different providers used (mostly static adapter with something, like Cloudflare, Vercel and probably soon will shift to Fastly), and base path hardly used (because lands embedded to sites managed by different partners).

The land itself placed in $lib, if we can support api in exact adapter we also import api handlers from $lib (can extend repo if needed)

Me fight for Svelte in every company I work.
All of them have projects on different frameworks and documented practices on how we look on our project's structure, etc. And it's always framework-agnostic. We have libs that are agnostic. (All that projects are often huge and related to business processes automation in most cases). So, it's not about "personally me want sources instead of src in my pet project", it's in common enterprise protocol.

And this is what I came up with in latest project:

assets/ (`files.assest = 'assets/'` instead of `static/`, sounds logical since `%sveltekit.assets%`)
lab/ (Light Agnostic Bundle, agnostic to framework, `git pull`ed)
les/ (Library Extending Svelte — agnostic to project, also `git pull`)
lib/ (current project specific lib we all now)
src/ (pages and components grouped by domain)
    users/
        user.svelte
        users.svelte
    groups/
        group.svelte
        groups.svelte
routes/ (code based router, more on it below)
    [...path]/
        +error.svelte
        +page.svelte
        +page.server.ts
        +page.ts

Ye, we want to be global lib (which is git pulled) in root to be on the same level with project specific lib...
And tech logic live in lib/, but business logic in src/ without any extra nestings

Also, our teem refuse to make our project structure depend on browser urls since marketing-managers can change it any time and as often as they want it to.
So we use our own code-based-router.
routes/ are just universal proxy for everything and we define routes in urls.ts like that:

import type { Pattern, Error } from '/router/types.ts';

const error: Error = () => import('/src/error.svelte');
const base: Layout = {page: () => import('/src/base.svelte'), error: error};
const layouts = [base];

const patterns: Pattern[] = [
    {re: '',                   page: () => import('/src/home.svelte'), layouts},
    {re: 'users',              page: () => import('/src/users/user.svelte'), layouts},
    {re: 'users/(<id>[0-9]+)', page: () => import('/src/users/users.svelte'), layouts},
]

export { patterns, error}

And we are happy with that.
(Sure it also needs config.kit.files.routes).

Honestly, when I first saw "The config.kit.files.routes option is deprecated, and will be removed in a future version" I felt panic.
It'll become much harder to fight for Svelte.
I'm not an expert to say what framework should do or should not, but as a developer, I'll be glad if frameworks were aimed to provide possibilities and freedom, so different users find/develop their own best practices suiting their needs, enterprise users can develop their best practices, indy-dev theirs and so on.
Big thx for raising that topic

P.S. I do understand the value of simplicity (but not unification among all kinds of projects), and I'll be ok with any other mechanism of reorganising paths that'll be easier to maintain from Svelte's side

I've been a Svelte user for a while now, and the flexibility of the kit.files configuration was actually one of the key reasons I chose SvelteKit over other frameworks. The ability to customize the file structure isn't just an "aesthetic" preference for me; it's a critical part of how I manage complex projects.

For example, in a current project, I have a monorepo setup where I share components and utility functions from a single $lib directory across multiple SvelteKit applications. Each application, however, has its own distinct set of routes and layouts. I'm able to manage this seamlessly by using the kit.files configuration to point to separate routes directories for each app, like this:

/** @type {import('@sveltejs/kit').Config} */
const config = {
	kit: {
		adapter: adapter(),
		files: {
			routes: 'src/routes/project-1',
			src: 'src/src-1',
			// ... other custom paths
		}
	}
};

This setup allows me to build a single application with shared $lib components while maintaining entirely distinct layouts and pages for different "sub-projects" or modules. For example, I can have src/src-1 containing specific source code and src/routes/project-1 defining the routes for a particular part of my application, all within the same SvelteKit instance, reusing common components defined in $lib.

I understand the goal of making SvelteKit more consistent and predictable, especially for new users and tools like LLMs. However, for those of us working on more unconventional, large-scale projects, this feature is a lifeline. I believe removing it entirely would be a step backward in terms of flexibility and would force developers to use "grubby" workarounds that are arguably less readable and harder to maintain than the current configuration options.

In my project, I keep both frontend and backend in the same repository, and it is crucial for me to at least specify my own root directory for the entire frontend structure.

Example stucture:

project/
    .git/
    server/ ( code of backend [use python] )
    webui/  ( code of frontend [use as Backend-for-Frontend] )
        lib/
        routes/
        app.html
        ...
    vite.config.js
    svelte.config.js
    package.json
    ...

@Rich-Harris Please reconsider deprecating this. It’s such an essential part of my workflow that its removal would make updating nearly impossible for me. I know I’m speaking for more than just myself, as many users rely on it without actively commenting here.

kit: { adapter: adapter({ out: 'build' }), files: { routes: `src/routes/${project}` }, alias: { '@/*': './src/lib/*', $assets: 'src/assets/*', $layout: 'src/layout/*', $components: 'src/components/*', $auth: 'src/auth/*', $server: 'src/server/*', $i18n: 'src/i18n/*', $ctx: 'src/lib/context/*', $socket: 'src/socket/*', $table: 'src/lib/layout/global/table/*', $default: 'src/routes/_default/*', $project: `src/routes/${project}/assets/*` } }

For those affected by this change: wouldn't a simple symlink to a custom directory accomplish the same result?

I apologize if this sounds naive but I didn't see any mention of this solution.

Supporting of configuration options for folder structure is crucial for monorepos. Workarounds like symlinks are problematic. Keeping customization options is vital for SvelteKit's adaptability to complex, real-world development scenarios, where SvelteKit often integrated within large existing codebases.

Similarly to @MegaDiablo, my personal and professional projects use SvelteKit in a repo where both the frontend and backends (Rust) live together. As a result, the src folder is subdivided, for example:

src
   backend1
   backend2
   backend3
   frontend

While one could argue that if config.kit.files were to be deprecated, all npm, Vite, and Svelte configuration could be moved inside the src/frontend subfolder, I personally think it’s cleaner and more maintainable to keep the configuration at the root of the repo rather than “hiding” it within a source subfolder.

In addition, our repo contains other tools - such as Node.js scripts - that share dependencies with the application. From that perspective, it also makes sense to keep the package.json and node_modules solely at the root of the repo.

Currently, my svelte.config are set up like this:

const filesPath = (/** @type {string} */ path) => `src/frontend/${path}`;

/** @type {import('@sveltejs/kit').Config} */
const config = {
	preprocess: vitePreprocess(),

	kit: {
		adapter: adapter({
			fallback: 'index.html',
			precompress: false
		}),
		files: {
			assets: filesPath('static'),
			lib: filesPath('src/lib'),
			routes: filesPath('src/routes'),
			appTemplate: filesPath('src/app.html')
		},
       ...

Examples:

• https://github.com/junobuild/juno
• https://github.com/dfinity/oisy-wallet

I understand the rationale, but this deprecation is defended as if SvelteKit were opinionated about folder structure, which it isn't.
"Here's a src/lib and a src/routes folder, do what you want with it" isn't sufficient to guarantee that a project won't turn into a giant mess as it grows. Therefore, we need to bring our own opinions about folder structure to the table. Which is fine, but without this feature, it seems like it will be much harder to do so.

Having a plan to structure a project at scale isn't just an aesthetic preference; it's a requirement. I wouldn't mind this change if it meant that SvelteKit would be more opinionated about folder structure as a result of it, but it doesn't look like it will be. So, in my view, this is a mistake.

I have a complex monorepo (turborepo + pnpm workspaces) that would significantly benefit from retaining config.kit.files options that I don't think kit.files.src can handle alone. It's not about aesthetic preferences for me, but more about eliminating complex workarounds.

Current Architecture

template/
├── apps/
│   ├── app/            # Sveltekit 
│   ├── docs/           # Sveltekit
│   ├── site/           # Sveltekit
│   └── storybook/      # Sveltekit 
└── packages/
    ├── config/         # shared configs for all apps
    │── tools/          # custom tooling for symlink creation
    └── ui/             # shared components lib for all apps
        ├── src/          # (workspace)
        └── static/       # (symlink)

Current Workarounds (that kit.files would eliminate)

1. Static Asset Sharing

Current solution: Custom symlink management via packages/tools

pnpm symlinks

With kit.files: Simple config per app

// apps/site/svelte.config.js
export default {
  kit: {
    files: {
      assets: '../../packages/ui/static'
    }
  }
}

2. Remote Functions Issue

Current problem: Remote functions only work within individual apps, not shared packages
With kit.files: Could potentially reference shared remote function directories

3. Shared Configuration

Current: Complex config inheritance via @packages/config-svelte

// packages/config/svelte/svelte.config.js - Master config
export default {
  kit: {
    adapter: adapter(),
    alias: {
      "@packages/ui": resolve("../../packages/ui/src/lib"),
      "@packages/tools": resolve("../../packages/tools/src"),
      $root: resolve("../../../"),
      $app: resolve("../../apps/app/src"),
      $docs: resolve("../../apps/docs/src"),
      $site: resolve("../../apps/site/src"),
      $storybook: resolve("../../apps/storybook/src"),
      $lib: "./src/lib",
    },
    experimental: { remoteFunctions: true }
  }
}

// apps/**
import config from "@packages/config-svelte";
export default config;

With kit.files: Simplified shared config, each app gets shared assets automatically

// packages/config/svelte/svelte.config.js - Much simpler master config
export default {
  kit: {
    adapter: adapter(),
    files: {
      assets: '../../packages/ui/static'  // All apps inherit shared assets
    },
    alias: {
      "@packages/ui": resolve("../../packages/ui/src/lib"),
      "@packages/tools": resolve("../../packages/tools/src"),
      $lib: "./src/lib",
    },
    experimental: { remoteFunctions: true }
  }
}

// apps/** (stays exactly the same - no symlink tooling needed)
import config from "@packages/config-svelte";
export default config;

Why This Matters for Monorepos

1. Eliminates custom tooling - No need for symlink management scripts
2. Simplifies scaling - Adding new apps becomes trivial configuration
3. Standard approach - Uses SvelteKit's native path system vs. custom workarounds
4. Cross-platform reliability - No symlink compatibility issues

We have a probably pretty esoteric situation:

We have two versions of this site: https://view.qiime2.org/

One version is deployed with a service worker (and thus needs a different config) and the other is vendored into a CLI application, with a different initialization involving a local ephemeral file-server.

It seemed at the time that the files.routes was a simple way to set up the different entry-points for the application. I mention this because we have a situation where the config is necessarily different, so we don't feel the pain of using an ENV var to swap things out, it just looks a bit like using webpack of old.

I imagine we could probably do the mono-repo approach and punt most of the application code out of sveltekit, but as largely Python developers, I don't think that would have occurred to us without this discussion.

Hello everyone,

I am currently using Electron.js with SvelteKit. I keep my Electron files in a main directory (main process) and my SvelteKit files in a renderer directory (renderer process). I want to avoid cluttering the project root, so I need a clean structure.

Accordingly, I corrected the config like this (minimal example):

const config = {
  kit: {
    files: {
      assets: 'renderer/static',
      hooks: {
        server: 'renderer/hooks.server',
        client: 'renderer/hooks.client'
      },
      lib: 'renderer/lib',
      params: 'renderer/params',
      routes: 'renderer/routes',
      serviceWorker: 'renderer/service-worker',
      appTemplate: 'renderer/app.html',
      errorTemplate: 'renderer/error.html'
    }
  }
}

However, it seems that by default, Svelte expects its files to be in the project root.

I've been using Svelte since 2019, and I'm excited about the roadmap and current trends. 99% of the updates have been truly user-friendly and beneficial. However, this particular change regarding folder structure is confusing to me and many others.
Perhaps I don't fully understand what's happening, but it feels like there is an attempt to strictly enforce a specific folder structure.

For junior developers just starting out, a standardized structure across all projects is convenient and understandable. But for enterprise projects—or anything more complex than "Hello, World!"—where Svelte might only be a part of the project, it shouldn't dominate the root folder or dictate the entire structure. That feels strange at best.

If I have misunderstood this change, could someone explain how I can maintain my custom folder structure? How should I configure the config file now?

So you're deprecating a useful feature that was not added for reasons "lost to time", but rather for user choice & flexibility. Guess some people indeed have forgotten about the importance of personal freedom.. Organizing my app a certain way is my choice, and having the ability to do so is a benefit. And the only listed, concrete functionality-based reason for doing so is... observability? That is not something the average person uses, it even clearly says to seriously consider using it before going all in! That's not something every project needs, but will EVERYONE be using DIRECTORIES? Yes sir!

The learnability argument is invalid because if someone can grasp how to use Svelte, they can grasp how to set folder paths in a configuration file.

LLMs as a reason is also invalid because they can't even do Svelte 5 yet, I've tried. The syntax is way too new (thanks to your new syntax with all the react-y "runes"), so they're useless for any new svelte application. With consistent changes like these I find it difficult to believe more people will switch to the latest, either, so how much new training data will they really get?...

The best part: the officially given reason for removing a useful feature:

... ugh.

Pathetic.

I have to create a new application today for a client that would require these configuration options, but I'm a bit unsure where this is going since the discussion started 6 months ago and therefore what configuration I should apply for this new project to be future-proof given that using the files options is the most straightforward way to me (as shared above). Should we expect breaking changes soon, or won't there be any changes, or will we move forward with a compromised solution that still provides some way to pass options?

Dudes, did I get it right, that due to kit.files.* deprecation it'll be that alternative:
https://svelte.dev/docs/kit/configuration#alias

Looks like it fits everything at a first glance

My use case: multiple route configurations from a single application

A single SvelteKit application that produces different builds by switching the routes directory via an environment variable:

// svelte.config.js
files: {
  routes: `src/${env?.BUILD_ROUTES || 'routes'}`
}

src/routes/ - production build (app lobby at root)
src/routes-demo/ - demo build (demo page at root)

Application code, components, and libraries are shared across builds. Only the route entry points differ per build target.

Workarounds without this option

• Symlinks: swap a symlink before every build, restore after - temporary directory renaming with extra steps. Bullshit.
• Separate packages: duplicate svelte.config.js, vite.config.ts, package.json, creating packages/demo/src/routes that links to the <root>/src/**. Bullshit also.
• Separate git branches: maintain different route sets in different branches - merge conflicts, constant branch switching, diverging histories
• Route groups: the natural candidate - put each route set in its own group like (app) and (demo). Fails immediately: SvelteKit errors with The "/(app)" and "/(demo)" routes conflict with each other when both groups contain +page.svelte at the same path. Route groups only control layout nesting, not route selection

Every workaround adds complexity, fragility, and maintenance burden to replace one configuration line that solves this cleanly.

I have a SvelteKit + Rust project. Cargo expects Rust source files in src/ for its source files, so when I added SvelteKit, I set kit.files.src to "app" and put the frontend code in app/. It would be quite inconvenient if this stopped working.

Just want to let folks know that we won't be deprecating kit.files.* in the near future. We're really thankful for all the use cases shared by everyone. It's helped us realise that the core of the issue is that people want to package provided routes or to switch directories/files based on environment variables, etc.. We're hoping to find the best solution for these use cases. Until that's available, the kit.files.* options are the most convenient way to do it.

I do think it would be really nice if we could do something like:

import { routes as authRoutes } from 'better-auth/svelte-kit';
import { env } from '$env/dynamic/private';
import { PLATFORM } from '$env/static/private';
import { cloudflareRoutes } from 'my-lib';

export default config = {
  kit: {
    routes: {
      configure((routes) => {
        if (PLATFORM === 'cloudflare') {
          routes.push(cloudflareRoutes);
        }
        
        if (env.ADMIN === 'true') {
          routes.push(authRoutes);
        }
      })
    }
  }
}