Remove fallthrough

[Rich-Harris]

Migrating away from fallthrough routes

If you ended up here because you previously used fallthrough routes and need to figure out how to migrate away from them, welcome.

If you were previously using fallthrough to render a 404 (i.e. you weren't actually falling through to a separate route), just return the 404 explicitly.

If you were using it to validate route parameters (i.e. you had [foo].svelte and [bar].svelte, and foo and bar had different requirements, you should use parameter validators instead.

If you need to vary which components are rendered based on some other condition (e.g. whether a piece of data exists in a database), then you can do this sort of thing:

<script context="module">
  export function load(args) {
    const module = some_condition(args)
      ? await import('./A.svelte')
      : await import('./B.svelte');

    const loaded = module.load ? await module.load(args) : {};

    return {
      ...loaded,
      props: { ...loaded.props, component: module.default }
    };
  }
</script>

<script>
  export let component;
</script>

<svelte:component this={component} {...$$restProps}/>

---

#4291, part 1 of 2. This removes fallthrough routes but doesn't add parameter validators (that's part 2).

I have a hunch that we can simplify client.js further, but that can happen in a follow-up

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https:/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: aa415d9

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

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

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

[UltraCakeBakery]

I am relying quite a lot on fallthrough routes in their current state. I don't want to get locked out of bug fixes while waiting for part two..

Is this a WIP kind of Pull Request, or will this actually get merged without any alternatives to fallthrough routes in the mean time?

[Rich-Harris]

It won't get merged until part two is ready — working on that now

[benmccann]

should you be allowed to have [...catchall].svelte and [b].svelte? It seems like [b].svelte will never be called, so maybe this should throw an error during build

[Conduitry]

They would both be allowed once we implement part 2 of this with route validators, right? (And that is going to happen immediately after this PR.)

[Rich-Harris]

[...catchall] is a rest parameter. regardless of part 2, it will match /things/b/will/not/match. We could throw an error for [a].js alongside [b].svelte, but I think we can do that separately to avoid bloating this PR

[benmccann]

I assumed this was the section where we showed the priority order of routes (GitHub collapsed the context around this). It looks like [..catchall].svelte is still last in the priority ordering. I wonder if we should show it last here as well for consistency?