fix: use name-based fallback in get_status/get_message when SvelteKitError crosses a bundle boundary

[Zelys-DFKH]

closes #15755

get_status and get_message in utils/error.js use instanceof SvelteKitError to decide whether to return the error's status code and text. When adapter-node bundles its own copy of @sveltejs/kit, the error object was created by one copy of the class but checked against another, so instanceof fails and the fallback 500 is returned instead of the real status.

The fix has two parts. First, both SvelteKitError and HttpError now set this.name in their constructors. That's a plain string on the instance, so it crosses any bundle boundary without issues. Second, get_status and get_message fall back to checking error.name when instanceof fails, the same way Node.js itself uses error.code strings instead of class identity for system errors.

A previous attempt (#15776) tried to mark @sveltejs/kit/node as external in the adapter-node rollup config. That didn't work because the second rollup pass in adapter/index.js bundles @sveltejs/kit from devDependencies anyway, leaving two separate class instances regardless.

[changeset-bot]

🦋 Changeset detected

Latest commit: b134596

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

[svelte-docs-bot]

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

[Zelys-DFKH]

Hey Elliott, thanks for the suggestion on the issue. I went down that path first (see #15776) and want to flag what I ran into.

Adapter-node bundles SvelteKit twice, in two separate passes:

1. The first rollup pass at adapter publish time bakes @sveltejs/kit/node into files/handler.js. That's where getRequest throws the SvelteKitError(413).
2. The second rollup pass runs at user build time inside adapt(). Its external regex only covers pkg.dependencies, and most users have @sveltejs/kit as a devDependency, so this pass inlines a fresh copy of SvelteKitError into the server bundle.

The error comes from copy A and gets caught against copy B. instanceof fails and the fallback 500 wins.

Marking @sveltejs/kit/node as external in the first pass (what #15776 attempted) doesn't quite close it. Even if files/handler.js resolves the import at runtime, the user's server bundle still has its own copy from the second pass, so the two instances stay different. To fix it at the source we'd also need to externalize @sveltejs/kit in the second rollup pass, which would mean production deployments need @sveltejs/kit installed separately. That breaks the self-contained output that makes adapter-node easy to deploy.

The name-based fallback in this PR sidesteps both copies. Both classes set this.name, and get_status and get_message fall back to that string when instanceof misses. It's the same shape Node itself uses with error.code for system errors, and it stays correct no matter how adapters bundle in the future.

Happy to take it in a different direction if you'd rather chase the source-level fix and accept the deployment trade-off. Let me know which way you want to go.

[Zelys-DFKH]

Friendly ping — this PR has been ready for review with all CI passing for 9 days. The fix uses a name-based fallback approach (as suggested in the issue) to handle SvelteKitError crossing bundle boundaries. Ready to merge whenever you have bandwidth! 🚀