Layout resets

[Rich-Harris]

Closes #626.

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

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts

[benmccann]

going to make a lot of people happy with this one! it was the #2 request from Sapper behind i18n 😄

[benmccann]

We should say something about the contents of $layout.reset.svelte. Would it be accurate to say:

To reset the layout stack, create an empty $layout.reset.svelte file.

[dummdidumm]

To me this sounds like it needs to be empty, which is not correct because you can start writing your new layout inside the reset file right away. Do I think the current sentence is better.

[Conduitry]

I'm not sure what would be best but I agree that the current proposed docs are a bit confusing. Maybe it would help if they said one creates the reset file instead of the regular layout file?

[Rich-Harris]

Made it a bit clearer

[Conduitry]

Had an API that uses a module export to indicate that this is a reset layout been considered? That seems in a sense tidier than a separate file, especially since they're not allowed to coexist. Was that dismissed because it made it harder to check for at compile time? because it's harder for users to see at a glance?

[Rich-Harris]

Addressed that in #626 (comment). tl;dr the manifest generator (which at present just looks at the names of files on the filesystem, and could theoretically be rewritten to take an array of strings, which is actually probably a good idea anyway) would have to a) know how to preprocess components, which incidentally implies becoming an async function, and b) be sufficiently good at static analysis that it understands all of these, and presumably an infinite number of weird edge cases:

export const reset = true;

const reset = true;
export { reset };

export const reset = some_value();

// export const reset = true;

Otherwise it would have to be determined at runtime by loading layout components higher up the tree, executing load (and hoping that they don't error), then discarding the result of calling load as soon as we encounter a reset.

In any case I think the filename is probably clearer insofar as you can understand the route structure by just looking at the filesystem.

[gudata]

Is it true that today the way of reseting layout is via the @ at the filename on page/layouts as pointed in docs ?

[JawadAzizi]

This should be mentioned on the docs page, possibly on this page: https://kit.svelte.dev/docs/advanced-routing#advanced-layouts