breaking: allow handleError to influence status code

[dummdidumm]

...by returning { status: ..., ... } from handleError.

Breaking change because theoretically someone could've used this as part of App.Error before, and now it's kind of outside that, a reserved property on handleError's return object.

Closes #14442

[changeset-bot]

🦋 Changeset detected

Latest commit: 196812d

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	Major

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

[svelte-docs-bot]

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

[dummdidumm]

/autofix

[Rich-Harris]

what if instead of doing it like this, App.Error always had a status property? we would update the error(...) helper like so:

// just a status, default message, works as today
error(418);

// status and message, works as today
error(418, `I'm a teapot`);

// pass an `App.Error` object — unlike today, omit the first argument
error({
  id: crypto.randomUUID(),
  status: 418,
  message: `I'm a teapot`
});

[Rich-Harris]

I suppose another option for the custom App.Error case would be this, if it's possible type-wise

error(418, `I'm a teapot`, {
  id: crypto.randomUUID()
});

[teemingc]

Agree on adding the status property to our interface. Prevents people from overriding it in app.d.ts with a different type (ours takes precedence and causes the type in app.d.ts to be ignored). Not sure how to get it to error at the interface so that folks know it doesn't take effect. I guess that becomes obvious if they do try to assign a value to it.

[Rich-Harris]

if it's possible type-wise

just took a run at this

type Custom = App.Error extends { status: number; message: string }
    ? { status: number; message: string } extends App.Error
        ? false
        : true
    : never;

declare function error(
    ...args: Custom extends true
        ? [status: number, message: string, body: Omit<App.Error, 'status' | 'message'>]
        : [status: number, message: string]
): never;

[Rich-Harris]

blocking pending resolution of #16162 (review)

[vercel]

Additional Suggestion:

Client-side handle_error returns an App.Error without a status field, so after CSR navigation errors page.error.status is undefined even though App.Error.status is now a required number.

[vercel]

Additional Suggestions:

1. Hydrating an SSR'd error page yields page.status === 200 instead of the real error status (e.g. 404/500) because _hydrate defaults status to 200, defeating the error?.status fallback.

2. Statusless action errors (e.g. a network failure during a progressively-enhanced form submit) now render the nearest +error.svelte with page.status === 200 instead of the previous 500, conflating a failed submission with a success status.

[Rich-Harris]

agree with the first vercel bot suggestion, not sure about the second

[dummdidumm]

The second point is correct, too, but not its fix. Pushing something up.

[pkg-svelte-dev]

Install latest

Install the latest version of @sveltejs/kit from this PR's head commit (196812d):

With spi (streams build progress):

spi @sveltejs/kit --commit 196812d140b7765f0b9856073b7708f910971d5a

With pnpm (waits silently):

pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/196812d140b7765f0b9856073b7708f910971d5a

Commit URL: https://pkg.svelte.dev/@sveltejs/kit/c/196812d140b7765f0b9856073b7708f910971d5a
PR URL: https://pkg.svelte.dev/@sveltejs/kit/pr/16162