feat: route-level entry generators

[elliott-with-the-longest-name-on-github]

Closes #9506

This allows exporting an entries function from +page, +page.server, and +server files:

// /[date]/[...file]/+page.server.ts
export const entries = () => {
  return [
    { date: '2022-01-01', file: 'some/path.docx' },
    { date: '2022-02-01', file: 'some/other/path.docx' }
  ]
}

This would cause /2022-01-01/some/path.docx and /2022-02-01/some/other/path.docx to be prerendered, regardless of whether they're reachable by the prerendering crawler.

To aid in debugging and help make this feature as footgun-less as possible, if an entries export creates an entry that matches a route other than its own, it will throw an error during prerendering. I added a config option to handle this similarly to how we handle other prerender errors.

Given the following two routes:

• /[slug]/[otherSlug]
• /[slug]/specific

If /[slug]/[otherSlug]/+page.server.ts exports the following:

export const entries: EntryGenerator = () => {
  return [{ slug: 'foo', otherSlug: 'specific' }]
}

This would throw a prerendering error with a descriptive message, because the entry resolves to /foo/specific, which matches [slug]/specific instead of /[slug]/[otherSlug].

TODO:

• Should we throw an error or something if routes generated from entries are duplicated? Should we just dedup them?
• Add typing support -- the return type should respect required and optional params
• Make sure typing and functionality works for export from +server.ts
• Tests
• Docs
• Build auto-typing into the language server
• Fix the "You can't use this export" error my editor is still giving me???

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[changeset-bot]

🦋 Changeset detected

Latest commit: fcb442a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Rich-Harris]

this looks great, i just had one minor piece of feedback about naming. i think we probably need to ship the type updates first though, otherwise people will get yelled at if they try and use this

[dummdidumm]

I think that's too little to add to the docs for this feature. We need some place to explain it properly.

[elliott-with-the-longest-name-on-github]

I agree -- I called this out in the PR description. I wasn't sure where we'd want to put this, though.

[geoffrich]

Probably in page options at the very least, and maybe also reference it in some of the prerender-related docs.