maybe improve types documentation a bit (#7003)

* throwing some ideas at the wall

* better doc visuals from interface definitions

* move types representation

* tweak visuals

* silence type error

* please?

* why don't I get these errors locally

* boxes

* border-radius

* auto-prepend "ignore any", remove jsdoc types hack which wrecks jsdoc hover code in editors

* remove this file in case we forget later

* visually group things more tightly

* collapse interface blocks

* dont run twoslash on ts blocks

* add links, fix some css

* minor fixes

* config types

* remove unused code

* move type extraction script as a precursor to reducing some of the indirection, to make it easier to work on nested properties

* distinguish between ts and dts

* hopefully fix deploy

* consistent format

* reduce indirection a bit

* nested properties, albeit with terrible styling at the moment

* more docs

* improve styles a tiny bit

* flesh out some stuff

* more stuff

* couple more

* move SubmitFunction into @sveltejs/kit types

* use /// type, so type hints get syntax highlighting

* add some defaults

* more defaults

* remove unused typedef

* consistency

* fix code snippet

* small tweaks

* small fixes

* tweaks

* rename API reference to just reference

* okay ts doesnt like that

* missed a spot

* changeset

* fix link

* refactor code in the direction of separating out config reference

* remove unused code

* systematise some stuff

* generate config docs

* get site building again

* hackiest possible workaround

* tweak some css

* tweaks

Co-authored-by: Simon Holthausen <[email protected]>

Author: Rich-Harris

.changeset/bright-pianos-flow.md

@@ -0,0 +1,5 @@
+---
+'create-svelte': patch
+---
+
+Update app.d.ts files

.changeset/light-toes-rush.md

@@ -0,0 +1,5 @@
+---
+'@sveltejs/kit': patch
+---
+
+Add more type documentation

.changeset/young-needles-attack.md

@@ -0,0 +1,5 @@
+---
+'@sveltejs/kit': patch
+---
+
+[breaking] move SubmitFunction into @sveltejs/kit

documentation/docs/20-core-concepts/20-load.md

@@ -243,7 +243,7 @@ export async function load({ fetch, params }) {
 
 ### Cookies and headers
 
-A server-only `load` function can get and set [`cookies`](/docs/types#sveltejs-kit-cookies).
+A server-only `load` function can get and set [`cookies`](/docs/types#public-types-cookies).
 
 ```js
 /// file: src/routes/+layout.server.js
@@ -544,7 +544,7 @@ To summarize, a `load` function will re-run in the following situations:
 - It references a property of `params` whose value has changed
 - It references a property of `url` (such as `url.pathname` or `url.search`) whose value has changed
 - It calls `await parent()` and a parent `load` function re-ran
-- It declared a dependency on a specific URL via [`fetch`](#making-fetch-requests) or [`depends`](/docs/types#sveltejs-kit-loadevent), and that URL was marked invalid with [`invalidate(url)`](/docs/modules#$app-navigation-invalidate)
+- It declared a dependency on a specific URL via [`fetch`](#making-fetch-requests) or [`depends`](/docs/types#public-types-loadevent), and that URL was marked invalid with [`invalidate(url)`](/docs/modules#$app-navigation-invalidate)
 - All active `load` functions were forcibly re-run with [`invalidateAll()`](/docs/modules#$app-navigation-invalidateall)
 
 Note that re-running a `load` function will update the `data` prop inside the corresponding `+layout.svelte` or `+page.svelte`; it does _not_ cause the component to be recreated. As a result, internal state is preserved. If this isn't what you want, you can reset whatever you need to reset inside an [`afterNavigate`](/docs/modules#$app-navigation-afternavigate) callback, and/or wrap your component in a [`{#key ...}`](https://svelte.dev/docs#template-syntax-key) block.

documentation/docs/30-advanced/70-packaging.md

@@ -10,13 +10,13 @@ When you're creating an app, the contents of `src/routes` is the public-facing s
 
 A component library has the exact same structure as a SvelteKit app, except that `src/lib` is the public-facing bit. `src/routes` might be a documentation or demo site that accompanies the library, or it might just be a sandbox you use during development.
 
-Running the `svelte-package` command from `@sveltejs/package` will take the contents of `src/lib` and generate a `package` directory (which can be [configured](/docs/configuration#package)) containing the following:
+Running the `svelte-package` command from `@sveltejs/package` will take the contents of `src/lib` and generate a `package` directory (which can be [configured](/docs/configuration)) containing the following:
 
-- All the files in `src/lib`, unless you [configure](/docs/configuration#package) custom `include`/`exclude` options. Svelte components will be preprocessed, TypeScript files will be transpiled to JavaScript.
-- Type definitions (`d.ts` files) which are generated for Svelte, JavaScript and TypeScript files. You need to install `typescript >= 4.0.0` for this. Type definitions are placed next to their implementation, hand-written `d.ts` files are copied over as is. You can [disable generation](/docs/configuration#package), but we strongly recommend against it.
+- All the files in `src/lib`, unless you [configure](/docs/configuration) custom `include`/`exclude` options. Svelte components will be preprocessed, TypeScript files will be transpiled to JavaScript.
+- Type definitions (`d.ts` files) which are generated for Svelte, JavaScript and TypeScript files. You need to install `typescript >= 4.0.0` for this. Type definitions are placed next to their implementation, hand-written `d.ts` files are copied over as is. You can [disable generation](/docs/configuration), but we strongly recommend against it.
 - A `package.json` copied from the project root with all fields except `"scripts"`, `"publishConfig.directory"` and `"publishConfig.linkDirectory"`. The `"dependencies"` field is included, which means you should add packages that you only need for your documentation or demo site to `"devDependencies"`. A `"type": "module"` and an `"exports"` field will be added if it's not defined in the original file.
 
-The `"exports"` field contains the package's entry points. By default, all files in `src/lib` will be treated as an entry point unless they start with (or live in a directory that starts with) an underscore, but you can [configure](/docs/configuration#package) this behaviour. If you have a `src/lib/index.js` or `src/lib/index.svelte` file, it will be treated as the package root.
+The `"exports"` field contains the package's entry points. By default, all files in `src/lib` will be treated as an entry point unless they start with (or live in a directory that starts with) an underscore, but you can [configure](/docs/configuration) this behaviour. If you have a `src/lib/index.js` or `src/lib/index.svelte` file, it will be treated as the package root.
 
 For example, if you had a `src/lib/Foo.svelte` component and a `src/lib/index.js` module that re-exported it, a consumer of your library could do either of the following:
 
@@ -54,7 +54,7 @@ To publish the generated package:
 npm publish ./package
 ```
 
-The `./package` above is referring to the directory name generated, change accordingly if you configure a custom [`package.dir`](/docs/configuration#package).
+The `./package` above is referring to the directory name generated, change accordingly if you configure a custom [`package.dir`](/docs/configuration).
 
 ### Caveats