[feat] easier creation of metadata / `stuff`

Describe the problem

Right now if you want to pass data from child to layout you do it via stuff. A common usecase is defining metatags. It can be a bit verbose to write this:

<script context="module">
  /** @type {import('@sveltejs/kit').Load} */
  export async function load({ stuff }) {
    return {
      stuff: {
        metadata: {
          description: 'page description here'
        }
      }
    };
  }
</script>

Describe the proposed solution and alternatives considered

Option 1

Take anything not in a known property and add it to stuff. Or potentially only properties whitelisted by the user. Then you could save a few lines of code:

<script context="module">
  /** @type {import('@sveltejs/kit').Load} */
  export async function load({ stuff }) {
    return {
      metadata: {
        description: 'page description here'
      }
    };
  }
</script>

The downside to this of course is that if we add any new property to the return value it’s potentially a breaking change. But we might be willing to make that tradeoff if the improvement in ergonomics is deemed sufficient and we felt it was unlikely we’d introduce many new fields to the return value

Option 2

Having stuff is nice because you can control the contents based on data dynamically fetched from the server. However, much of the time that is unnecessary and the data is simply static. It could also be nice if you could write something like this in the child node:

<script context="module">
  export const metadata: {
    description: 'page description here'
  };
</script>

We could make the leaf node available to load.

Option 3

Similar to option 2, but instead of making just the leaf node available, we could make an object with the fields in each layout / child with the children overriding the parents and then make it available in load. The trickiest part of this would probably be how to refer to it and differentiate it from stuff in the API

Option 4

Create a new variable like statics that you can define outside of load that SvelteKit will make available in load. This is similar to the last option in some ways, but only works with a single SvelteKit-defined property

Importance

nice to have

Additional Information

No response

[mrkishi]

Seconding Con on this one, especially as we would lose forwards compatibility since any added properties would be breaking changes. Well, I guess they wouldn’t be breaking in the whitelisting case, but it’d still be a hassle for little upside.

Having direct access to the module so you can get exported data might be less troublesome, although I’m not sure whether it’d come with its own set of warts.

[Conduitry]

I really don’t like “any unknown options get treated as such-and-such” APIs. That would include “everything that’s not one of the known load return keys gets put into stuff” and “every module export from the component that’s not load/ssr/prerender/etc. gets put into stuff”.