[teemingc]

Fixed #12556

---

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.

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.

[pkg-svelte-dev]

Install the latest version of @sveltejs/kit from 8ab1c3e:

pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/8ab1c3eafee04b2d06867377a7805e828e4754e0

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/kit/pr/16903

[changeset-bot]

⚠️ No Changeset found

Latest commit: c507758

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[svelte-docs-bot]

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

[teemingc]

@Nic-Polumeyv can you explain how the fix works? What happens to ISR routes with dynamic segments? Are they disallowed now or do they just still work?

[Nic-Polumeyv]

No problem, took me a couple hours to figure out!

Vercel resolves a request in three steps (first match wins):

1. routes listed before `handle: filesystem`
2. filesystem: a file or function at exactly this path? (/foo and /foo/ both count)
3. routes listed after `handle: filesystem`

adapter-vercel put every ISR src route in step 3. Only a src route attaches __pathname; a filesystem hit passes nothing, so the function only ever sees its own file path.

/isr/[slug] never gets caught by step 2. Its function is the file isr/[slug].func and no request has that path, so it falls through to step 3 and the src route captures the URL. /isr-trailing-slash does get caught by step 2, because its function is the file isr-trailing-slash.func, which is its URL:

GET /isr-trailing-slash/
  step 2: isr-trailing-slash.func exists → run it, no __pathname
  function sees its own path: /isr-trailing-slash (slash lost)
  kit: trailingSlash 'always', no slash → 308 to /isr-trailing-slash/
GET /isr-trailing-slash/
  same again

The (/)?, %2F and (/?) commits changed the src regex for /isr-trailing-slash in config.json. That regex is in step 3. Vercel never ran it, because step 2 had already served the request.

The fix puts ISR routes with no dynamic segments in step 1. Dynamic ones stay in step 3, since a [...rest] ISR route in step 1 would swallow every static asset.

Separately, dest no longer rebuilds the pathname from route segments. The src regex is wrapped in one capture group and dest is ?__pathname=$1, so the function gets the path as requested. That is what deletes get_pathname and the // cleanup in the wrapper.

Dynamic ISR routes still work, nothing about their placement changed. The one difference is /isr/alpha/ now 308s to /isr/alpha instead of being served, same as the other adapters.

[Rich-Harris]

brilliant!