move kit runtime, expose via $app alias

[Rich-Harris]

Ref #58. Adds a $app alias for importing stuff specific to your app:

import { goto, prefetch, prefetchRoutes, start } from '$app/router';
import { getStores } from '$app/stores';

Currently involves a bit of a funky workaround for FredKSchott/snowpack#1395.

[Rich-Harris]

Added something new. Having to do this, or its Sapper equivalent...

import { getStores } from '$app/stores';
const { page, preloading, session } = getStores();

...has always been a nuisance. The reason we have to do it is that stores are necessarily contextual, so that you don't get the same store as someone else hitting the same server, potentially leaking information.

But it occurs to me that you could expose facade stores...

import { page, preloading, session } from '$app/stores';

...that 'link' to the real ones as soon as you subscribe. The only constraint is that you do in fact subscribe, and that you do so when context is discoverable (i.e. during component initialisation), but that covers 99% of cases, because Svelte subscribes automatically when it sees this:

<h1>Hello {$session.user.name}!</h1>

The getStores function could still be exposed for the remaining 1% of cases.

We can't safely set or update the session store during SSR, but that's something you shouldn't be doing anyway, so we simply disallow it. (TODO for some reason it doesn't like my use of import.meta.env.SSR.)

Now I'm wondering if there's a smart way to make your own custom stores that have similar behaviour to session, minus the automatic prepopulation.

[ehrencrona]

If the import of the runtime code does not start with @sveltejs/kit, we'd need to think of some other way of building the typings. In #68, the typings are found in e.g. client/index.d.ts and can therefore be resolved under @sveltejs/kit/client without any further configuration.

We can of course point to an ambient type definition in a tsconfig.json in the project, but I have not found any way of making that work with automatically generated typings (if you generate them as a single file, you cannot influence the module name and you don't seem to be able to re-export them under a new module name either).

It might be possible to auto-generate the typings and then search-and-replace the module names (or maybe there is a plugin of some kind that does this transformation).

[Rich-Harris]

I'm going to merge this anyway, as changing the aliases is a single line whereas this PR is really more about the code organisation.

We have other problems with aliases anyway:

This happens because TypeScript doesn't understand that $components/Counter.svelte corresponds to src/components/Counter.svelte. I thought I could fix it like so...

"compilerOptions": {
  // ...
  "baseUrl": ".",
  "paths": {
    "$components/*": ["./src/components/*"],
    "$app/*": [".svelte/main/runtime/*"]
  }
},

...but I don't think my brain has the necessary wiring to configure a TypeScript project. My understanding was that solving this sort of thing (and the $app/stores aliases, etc) was exactly what "paths" was for.

[ehrencrona]

Yeah, the TS configuration is driving my slightly crazy too.

The paths setting seems to make VSCode resolve to the right source file for me. On the other hand I don't get an error if the source file is missing (line below).

I suspect the error you get is because for whatever reason you don't have these typings that I have in .vscode/extensions/svelte.svelte-vscode-102.3.0/node_modules/svelte2tsx/svelte-shims.d.ts

declare module '*.svelte' {
    export default Svelte2TsxComponent
}

declare class Svelte2TsxComponent<
    Props extends {} = {},
    Events extends {} = {},
    Slots extends {} = {}
> {
    $$prop_def: Props;

[dummdidumm]

Let's continue this in #82