Reinstate types

[Rich-Harris]

Now that things are settling down and we're nearing a public beta, I think it's worth getting types back in the project. I've been spoiled by build-free JSDoc types and strongly believe that's the right approach for this repo (or at least, most packages in this repo) so I think we should see how far we get with that

[benmccann]

Most of the sub-packages are small enough that they can be build-free - though kit is still built. Would the plan be to make kit build-free as well?

I think the main pain point with the TypeScript last time around was that we didn't have a CI setup, so people were constant breaking the configuration because they'd have previously built locally and didn't realize things were broken when they had files hanging around from their previous build. I expect that it'd be much more pain-free this time around now that we have a CI (plus I have fixed a couple bugs in @rollup/plugin-typescript which should make it a lot less fiddly). It might be interesting to use JSDoc in one of the main packages and TypeScript in another one so that we can compare over time what we like vs. don't like with each.

[GrygrFlzr]

How should typing of user-written functions like load or server routes be handled? In kit-docs I tried Rich's suggestion of JSDocs-only using a global d.ts file, which seems subpar, but did get the job done.

However, if the create-svelte template includes these types inside the globals.d.ts file, they could eventually become outdated. I'm not sure what the proper way to solve this is, or if it even exists, given that the last time I asked in the TypeScript discord I was admonished for trying to support such an indirect use case.

[dummdidumm]

Types should definitely be generated or at least written by hand and provided as is so that people can use TS in their projects with ease. Using JsDoc in Kit should not harm the UX for devs using Kit with TS.

[Rich-Harris]

The really nice thing about 'build free' is that it's really 'build optional'. Kit is built, because it results in a faster installation and startup (the latter of which is particularly crucial for a CLI) but the trade-off is that developing Kit itself is significantly more complex. If it was possible for svelte-kit.js to point at either dist or src depending on whether we're developing it or using it, it would make lots of things easier.

[Rich-Harris]

Closing as this is basically done, except in the adapters, which is dependent on a resolution of #439