-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: route-level entry generators #9571
Conversation
🦋 Changeset detectedLatest commit: fcb442a The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
This reverts commit 05c7d4e.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Co-authored-by: Rich Harris <richard.a.harris@gmail.com>
@@ -33,7 +33,7 @@ export const prerender = 'auto'; | |||
|
|||
> If your entire app is suitable for prerendering, you can use [`adapter-static`](https://github.com/sveltejs/kit/tree/master/packages/adapter-static), which will output files suitable for use with any static webserver. | |||
|
|||
The prerenderer will start at the root of your app and generate files for any prerenderable pages or `+server.js` routes it finds. Each page is scanned for `<a>` elements that point to other pages that are candidates for prerendering — because of this, you generally don't need to specify which pages should be accessed. If you _do_ need to specify which pages should be accessed by the prerenderer, you can do so with the `entries` option in the [prerender configuration](configuration#prerender). | |||
The prerenderer will start at the root of your app and generate files for any prerenderable pages or `+server.js` routes it finds. Each page is scanned for `<a>` elements that point to other pages that are candidates for prerendering — because of this, you generally don't need to specify which pages should be accessed. If you _do_ need to specify which pages should be accessed by the prerenderer, you can do so with the `entries` option in the [prerender configuration](configuration#prerender), or by exporting an entry generator from your dynamic route. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's too little to add to the docs for this feature. We need some place to explain it properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree -- I called this out in the PR description. I wasn't sure where we'd want to put this, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably in page options at the very least, and maybe also reference it in some of the prerender-related docs.
Closes #9506
This allows exporting an
entries
function from+page
,+page.server
, and+server
files: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: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:
entries
are duplicated? Should we just dedup them?+server.ts
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. Changesets that add features should beminor
and those that fix bugs should bepatch
. Please prefix changeset messages withfeat:
,fix:
, orchore:
.