Clarity around prerendering behaviour of "entries"

[infovore]

I've finally solved a problem related to prerendering, and I cannot tell if this is intended behaviour or not. If it is, then there's probably a documentation tweak required (which I'd be happy to work on).

Background

I'm using SvelteKit to build a Sufficiently Advanced Static Site - that is to say, a big pile of Markdown, a variety of routes for pages and structures, plus some front-end only components. A modern website, basically. Most of it can be prerendered, because none of it changes per user - even the dynamic JS stuff. That means all the Markdown can stay local, and doesn't need to be bundled up in the deployment.

The issue

I have (to simplify) a set of routes that resemble /articles/[slug]/+page.svelte; this means (as far as I had understood) that I can't just use export const prerender = true, because it's not clear to SvelteKit what the final URLs will be. Also, for $reasons, I don't wish to crawl the site; I'd rather specify precisely which pages to render.

So, in svelte.config.js, I calculate the URLs for all the pages to prerender, and pass them as an option to kit.prerender.entries.

When I build the site, this does not prerender them. I was really stumped by this.

The solution

It turns out that if you have a path in kit.prerender.entries in your config, but the matching route (either +page.ts or +page.server.ts) is not marked as prerenderable with export const prerender = true, the page won't prerender.

This is not necessarily a bad thing - it just wasn't clear from the documentation that the two prerender statements serve different purposes:

• export const prerender = true means this route can be prerendered
• the list of paths in kit.prerender.entries is a set of routes that should be attempted to be prerendered.

When framed like that, it makes sense, but the distinction wasn't clear to me from the documentation.

So, my question is: have I now understood correctly?

Possible improvements

If I have understood correctly, a minor tweak to documentation would help clarify this for sure.

If I were to suggest a tweak in code, I would suggest that the constant exported from a load script be renamed to prerenderable, indicating what the variable actually represents. My main criticism of this idea is that it's an ugly word that perhaps isn't obvious to non-native English speakers.