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: 16f552d

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.

App.Error now has status property