Support named layouts for the error page, e.g., __error@root.svelte, to remove hardwired dependency on __layout.svelte

Describe the problem

Currently, __error.svelte is hardwired to __layout.svelte. In several of my projects, I use __layout.svelte for non-trivial purposes, including authentication guards, and of course rendering part of the page. This makes it nearly impossible to use __error.svelte to set up a global error page:

• The error page tries to display the shared page layout, which may be undesirable, and may re-trigger the error, or another error.
• Authentication guards may attempt expensive operations, redirect to a login page, or trigger another error.

I've tried to work around this by saving the error information and redirecting to a normal page to display the error, but the approach is cumbersome and fraught with problems:

• There is no way to detect, in __layout.svelte, that the error page is running. The URL path is the (possibly bad) path of the page that triggered the error.
• There's no good way to get the error information (error, status) to the next page. Using the session store may work, but may cause further problems or interfere with use of the session store for other purposes (such as server-to-client communication).
• It's not clear where or how to redirect out of the error page, and this may lead to further problems.

This has been a nightmare. I couldn't get it to work--I kept running into cascading issues--so I gave up (see Alternatives, below).

Describe the proposed solution

A simple solution would be to allow the error page to specify a parent layout (just like any other page, with the new named layouts):

__error@root.svelte

This could be an empty layout, which would remove dependencies on other parts of the app, making the error page less likely to fail. Similar to 2694 but adapted for the new named layouts.

Alternatives considered

Using a catch-all path in the route root will capture any unknown page, and this can specify a named layout:

[...anypath]@root.svelte

But this will not have access to actual error information, such as the stack trace, in development.

Importance

would make my life easier

Additional Information

The new named layouts were a bit hard to understand at first, but they are extremely powerful, and I'm sold on this. Fixing this would complete the picture, IMHO. As always, thanks to everyone for your hard work.

Start by comparing the proposed __error@root.svelte behavior with the existing __error.svelte and __layout.svelte relationship, then review how named layouts and [...anypath]@root.svelte are described in the linked layouts documentation. Done means an error page can select a parent named layout without inheriting the hardwired layout or losing the error information described here.