Prerender static files where possible

e.g. in the case of https://github.com/sveltejs/hn.svelte.dev/pull/27, the ‘about’ page could be prerendered.

It requires answering two questions:

How do we know whether a given page is prerenderable?

It can’t realistically be inferred from things like whether or not preload exists (/blog/some-post will have a preload but could be prerendered, /time-now is dynamic but might not have a preload), so I imagine we need to make it explicit, similarly to how Next has getStaticProps vs getServerSideProps.

My favourite idea so far:

<script context="module">
  export const metadata = {
    static: true
  };

  export function preload(page, session) {
    // ...
  }
</script>

Alternatively we could export a boolean directly, but export const static = true isn’t allowed (static is a reserved word) so we’d either need a synonym like export const prerendered = true or else export const dynamic = false, which feels weird.

How do we find pages in the first place, to test whether or not they are prerenderable?

In other words how do we find /about, in the hn.svelte.dev example?

We can’t just start from / and crawl, like we do in adapter-static, because we can’t prerender / — it’s dynamic. We do have some options though:

• We could specify a list of entry points in svelte.config.js or via the CLI (as currently happens with sapper export)
• We could look at all pages in the manifest that don’t have parameters
• Both of the above

There could be a situation where prerenderable pages on a route with parameters (routes/foo/[bar].svelte) are only reachable via a non-prerenderable index. In this case, the children are undiscoverable without a) specifying them as entry points, as above, or b) getStaticPaths, which I really don’t love. I’m inclined to view these cases as sufficiently anomalous as to not worry about.

---

Thoughts on any of the above?

[Conduitry]

Despite the general move here being to unify Svelte and Sapper, I still think their APIs should be kept somewhat separate. <svelte:options> controls things about this particular component in isolation. The Svelte compiler can’t really do anything with this flag besides expose it in the compiled code, which is precisely what <script context="module"> is for.

Svelte 1 and 2 had special handling for preload which just exposed that function on the constructor for the benefit of Sapper, and that part of the API always felt weird, and I’m glad we were able to get rid of that in Svelte 3. Having this live in <svelte:options> feels like a similar step backwards.

[dummdidumm]

Could <svelte:options> be a place where this is added to?