feat: provide cache to reroute

[urmoov-dev]

This PR fixes #13653 by allowing the reroute hook to control route caching behavior through a cache parameter. By passing the cache Map reference (Map<string, Promise<URL>>) to the hook, developers can selectively clear cache entries (e.g., by looping through specific routes or clearing all entries) to force the hook to re-run on subsequent requests. This is useful when rerouting depends on client state (cookies, headers, etc.) to determine layouts or route handling.

In two projects, I was already using the reroute hook for this type of behavior, but after updating from 2.18, the reroute_cache broke my apps. I tested this patch manually by applying it directly to node_modules in both projects, and it successfully allows fine-grained control over which routes bypass the cache.

---

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://github.com/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.

  Tested manually in two existing projects by overriding pnpm to this clone. The feature works as expected, allowing selective cache invalidation. I'm happy to add automated tests if maintainers provide guidance on the preferred test structure for this behavior.

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 pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

🦋 Changeset detected

Latest commit: c5cb2e0

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	Minor

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

[elliott-with-the-longest-name-on-github]

The docs for reroute say this:

reroute is considered a pure, idempotent function. As such, it must always return the same output for the same input and not have side effects. Under these assumptions, SvelteKit caches the result of reroute on the client so it is only called once per unique URL.

I'm not necessarily saying this is a bad feature or something we definitely should not do, but it is definitely against the currently-stated purpose of reroute, so it needs some discussion with the team. Thank you for the time implementing -- I'll make sure we get time to talk about it!

[urmoov-dev]

The docs for reroute say this:

reroute is considered a pure, idempotent function. As such, it must always return the same output for the same input and not have side effects. Under these assumptions, SvelteKit caches the result of reroute on the client so it is only called once per unique URL.

I'm not necessarily saying this is a bad feature or something we definitely should not do, but it is definitely against the currently-stated purpose of reroute, so it needs some discussion with the team. Thank you for the time implementing -- I'll make sure we get time to talk about it!

Hey Elliot! That's why I made this Reddit post pondering whether it should actually be considered a pure, idempotent function when in its initial implementation (before async in 2.18 and specially the cache introduction in 2.19) it allowed for much more functionality. I 100% agree with the reasons why those were implemented as a standard behavior and the point of this PR is not to change that, but to also give the developer the choice in case they want/need those functionalities and accept the performance penalties. I hope this helps clarify and I make myself available for any further clarifications and discussions. Thanks for your reply and for considering this change!