Option to pre-render the dynamic routes

[johnnysprinkles]

Currently you can use a '*' as a wildcard in kit.prerender.pages to specify all non-dynamic routes. This adds a new token to do the dynamic routes, initially picked to be '**' but could be anything.

When pre-rendering a dynamic route, also creates the convention that params are filled in with the param name in square brackets, such that if you have a route like:

/article/[slug].svelte

Which would be concretely referenced by the user as say "https://mysite.com/article/cool-article", the resulting HTML artifact in the /build folder lives at:

/build/article/[slug]/index.html

This relates to sveltejs/rfcs#52 and #1561, and enables one to use adapter-static to generate artifacts which can be used in any type of server runtime, even if you have dynamic routes. Obviously in such a scenario, any parts of the page that depend on request-specific data would need to be client-rendered. This essentially enables a "static SSR / client-rendered" hybrid, where the shell of the page is static prerendered and some inner data-driven part is client-rendered.

Not very optimistic this will get approved, but taking a shot anyway. If this needs to go in a fork of SvelteKit, that's understandable.

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 pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

⚠️ No Changeset found

Latest commit: 37ce4c8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[benmccann]

How would someone visiting article/cool-article be served article/[slug]/index.html?

[johnnysprinkles]

How would someone visiting article/cool-article be served article/[slug]/index.html?

So there's how I plan to do it, how someone could do it generally serverful, and maybe how it could be done serverless.

I'll end up having a Java (or maybe Kotlin) web server that loads all those HTML files into memory, maintaining their tree structure, and just splits the request path into parts and looks for each part, falling back to a part name involving square brackets if that exists. Failing that it would serve the 400 page.

The same idea could work for serverful setups involving Java, Python, NodeJS, whatever you like. I worked at a company one time that used Django (this was offerup.com), and I can imagine wanting to iteratively migrate pages over from Django to Svelte without the added architectural complexity of putting a reverse proxy in front. One could simply have Django serve the static files, even when the paths have wildcards.

Happy to make an example reference implementation of a "serve the static assets" in whatever language you like, or pseudocode.

For serverless, one could copy all the /build folder up to say AWS S3 and serve it via Cloudfront. In this case you'll need some path rewriting, which actually you'd need anyway to serve the index.html files. So you transform a request for / to serve the file /build/index.html off disk. For these parameterized routes, you'd have to add some path rewriting that says for example /article/* => serve /build/article/[slug]/index.html. All this rewriting can be done in AWS with Lambda@Edge, simple Node functions to rewrite the URL. I think for this serverless approach you'd have to duplicate the route information, because it probably doesn't have access to the build artifacts from code.

[benmccann]

I don't think we'd want to add something that requires the user to do so much work to use. Anything we added should probably be supported by at least one of the SvelteKit adapters.

[johnnysprinkles]

Fair enough. Not having this isn't really blocking anybody, it just means they'll need to duplicate the route information as determined by the folder structure, in the svelte config. Perhaps we can revisit this if other people end up wanting to do the same thing, that is using static pre-rendering for the general case, which will often include parameterized paths.

I'll close, but glad this is on record and people can refer to it if they want. For what I plan to use SvelteKit for in the enterprise environment, we probably wouldn't even be productionizing until a year from now, so it's not urgent anyhow.