🦋 Changeset detected

Latest commit: 1ca24f2

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Preview: https://svelte-dev-git-preview-kit-14152-svelte.vercel.app/

I'm writing in response to the recent deprecation of kit.files.src, specifically concerning the kit.files.routes configuration. The ongoing efforts to refine SvelteKit and enhance its simplicity and consistency are deeply appreciated, as these are core strengths that draw many to this exceptional framework.

However, this particular deprecation poses a significant architectural challenge for our organization and, it is believed, for a segment of the SvelteKit community building complex, multi-application systems. There is currently a heavy reliance on the ability to configure kit.files.routes to manage multiple distinct application entry points (typically 5-10 different /routes folders) within a single monorepo. This setup, combined with a shared $lib and environment variables like VITE_ROUTE, allows for the production and deployment of different parts of an application to distinct domains from a unified codebase. This pattern is not merely a preference but a fundamental aspect of the architecture for managing multiple product variants, micro-frontends, or multi-tenant applications efficiently.

This approach enables:

Efficient codebase management: Maintaining a single repository for related applications, simplifying version control, dependency management, and ensuring atomic changes across features.

Shared common logic: Leveraging a shared $lib across all application variants without code duplication, promoting consistency and maintainability.

Optimized deployments: Creating distinct, optimized build artifacts for each application variant. This is crucial for performance and avoiding shipping unnecessary code, a goal that cannot be fully achieved with runtime solutions like reroute hooks or parameter matchers alone, as they still bundle all routes into the production output.

Facilitating multi-tenant/feature flagging: Seamlessly serving different tenant experiences or activating specific feature sets from the same source, with the selection occurring efficiently at build time.

The desire for consistency and improved tooling is understood. However, for these advanced scenarios, current alternatives fall short. Runtime solutions like the

reroute hook are valuable for URL manipulation and access control but do not influence the build-time route discovery process or prevent unused routes from being bundled. Similarly, while general monorepo tools like Turborepo and Nx excel at project orchestration, they do not offer a SvelteKit-native way to select a specific routes directory for a given build, a capability that Vite itself often supports but SvelteKit's CLI currently restricts.

To bridge this gap and support the evolving needs of complex SvelteKit applications, the following options are respectfully suggested for exploration:

Reinstating kit.files.routes with clear scope: Reconsider retaining kit.files.routes (perhaps renamed to kit.build.routesDir or kit.source.routes for clarity on its build-time impact) as an explicitly supported advanced configuration for multi-app scenarios.

Explicit Mechanism for Multiple Route Entry Points: Introduce a new configuration, e.g., kit.routes.entryPoints: string, allowing developers to define multiple root route directories and select one at build time via an environment variable or CLI argument.

Custom Route Discovery Plugin API: Provide a svelte.config.js hook that allows developers to implement custom logic for discovering and defining the routes included in a build, offering maximum flexibility for highly customized scenarios.

A solution that thoughtfully balances SvelteKit's core principles with the flexibility needed for these advanced use cases would significantly benefit the broader community and encourage even wider adoption of SvelteKit for enterprise-grade complex applications.

also related to: #14144

We produce lots of different ad onboarding flows, and also implement them as different routes in one repo. Like one lib folder, where identics and common staff stay. And 34 different route folders with different landings and custom onboarding flows for different domains.
It means that we are hardly (at least 34 times) dependent on that feature:)

We're not going to make any effort to support aesthetic preferences, but definitely want to make sure people can build complex apps.

@assiyakh-blip I suspect the best solution for you would be to use a monorepo with pnpm, but if you've tried that and it doesn't work for you could you open a new GitHub discussion and link it here? Comments on a closed PR are likely to get lost

I also want to express my support for bringing back kit.files.routes.

The removal of kit.files.routes breaks an important use case: maintaining multiple routes-* directories for different build targets (e.g. adapter-static for SPA/SSG, and another adapter for SSR).

Previously, it was possible to switch between these setups just by changing config. Now the only workaround is to move/rename folders before build, which feels hacky and fragile.

It would be great if either:

• kit.files.routes could be restored, or
• an alternative mechanism is provided to point SvelteKit to a specific routes directory per build scenario.

This flexibility is essential for projects that need to support multiple deployment modes.

I've opened #14240 for this discussion — let's continue over there. Thanks!