Type Context and Props

[puchesjr]

Is your feature request related to a problem? Please describe.
The inability to define types for context and props is less than ideal for the development process.

Describe the solution you'd like
Ideally, would love to see the ability to define types for context and props.

Describe alternatives you've considered
We have considered and currently declare types during the variable declaration within the route.

How important is this feature to you?
This feature would help our development with potential bugs, autocomplete and type hints, and we think it would be beneficial for many throughout the Svelte ecosystem.

Additional Context
https://github.com/sveltejs/kit/blob/master/packages/kit/types/page.d.ts

export type LoadOutput = {
	status?: number;
	error?: string | Error;
	redirect?: string;
	props?: Record<string, any> | Promise<Record<string, any>>;
	context?: Record<string, any>;
	maxage?: number;
};

[Rich-Harris]

In an ideal world, we'd be able to generate types for props automatically based on what's exported from the main script. i.e. if you have this...

<script>
  export let foo: string;
</script>

...then this would be typed automatically:

<script context="module">
  /** @type {import('$this'}.Load */
  export function load() {
    return {
      props: {
        foo: 42 // type error — number is not assignable to string
      }
    };
  }
</script>

See #647. No idea if this is possible

[benmccann]

I'm going to close in favor of #647

[dummdidumm]

I don't think these two are strictly related. This specific request can also be handled by expanding the LoadInput / LoadOutput interfaces with generics for these types. The user can then provide these if he wants better type checking.

[puchesjr]

I'm going to close in favor of #647

Tired of just seeing issues closed without trying to understand the full context.

[benmccann]

We want to do this. But this is a subset of #647. Implementing #647 would require implementing this one as well and I didn't think it made sense to have two tickets to track it

There's also a PR open for this so even if we reopened it would be closed shortly when that PR is checked in so I'm not sure that it's really meaningful whether we reopen this or not