Throw an error (or warn?) if using adapter-static with invalid routes

[Rich-Harris]

Describe the problem

adapter-static is a source of confusion for people who believe that it allows you to somehow publish an app with dynamic server rendering and/or endpoints with POST/PATCH/DELETE/etc handlers to GitHub pages.

Describe the proposed solution

I haven't thought deeply about the implementation, beyond this:

• If pages are left unprerendered, adapter-static should throw an error unless fallback was specified.
• If an endpoint has non-GET handlers, adapter-static should throw an error regardless of whether fallback was specified.

Alternatives considered

More complete documentation, and spending more time dealing with issues

Importance

would make my life easier

Additional Information

No response

[Mlocik97]

I'm for warn, but not error... Sometimes I want to have implemented endpoints with post/patch/delete or hooks and other dynamic server stuff, and use adapter-static for example if you want to implement website (using node resp. adapter-node or some server-less one), but at the same time use same source codes to generate static assets for for example electron/neutralino app, or nativescript mobile app. Then I have two adapters in config, and two build commands that build for website or app based on for example process.env. So error would "break" this. But there should be warn definitelly.

[Rich-Harris]

Prerendering happens automatically, regardless of what adapter you're using. In the rare case that an adapter doesn't specify where the prerendered output should be copied to, it's accessible at .svelte-kit/output/prerendered, so I'm not sure there's I understand why there's a reason to run adapter-static alongside a separate adapter.

[Spenhouet]

I'm a bit confused about what's supposed to work and what not.

I'm using the page routing (via slugs in file names), matchers and page endpoints (only GET). It's working when starting the dev environment but not when building it with adapter-static and deploying it to gh-pages.
Which of these three features should generally work with adapter-static? Are there any caveats?

Not going into any specifics here. If you say all three features generally should work, I will dig deeper and eventually open an issue to sort it out.

[Spenhouet]

Okay, I can give some answers to that myself. All three functions also work with adapter-static.

For page routing and page endpoints one just needs to use prerender.entries in the svelte.config.js.

For example for items/[id].svelte and items/[id].js:

kit: {
  prerender: {
	  default: true,
	  entries: ['*', '/items/1'],
  },
}

The list of entries to prerender can actually be generated similar to how it's done in this blog post: https://reecemay.me/articles/tip_sveltekit_static_pages_with_prismic/

For the matcher one needs to add a fallback for pages not matching the matcher and a fallback for slugs which match but have no prerendered page.
To make a fallback for slugs not matching the matcher, one can define a items/[...nomatch].svelte page.
To make a fallback for none existing slugs I needed todefine a items/__error.svelte page and set fallback: '404.html' in svelte.config.js for adapter-static. With fallback: null it does not seem to work (might be a bug?).

It would definitely help to mention these details in the docs on routing with respect to adapter-static.

[Mlocik97]

Prerendering happens automatically, regardless of what adapter you're using. In the rare case that an adapter doesn't specify where the prerendered output should be copied to, it's accessible at .svelte-kit/output/prerendered, so I'm not sure there's I understand why there's a reason to run adapter-static alongside a separate adapter.

sometimes I have reason to not prerender (for adapter-node), mainly if it shows different content to different users.