adapter-static has issues with server endpoints

[johnnysprinkles]

Describe the bug

One last issue on my big SvelteKit 350 to 551 upgrade... I'm using adapter-static to spit out some HTML files and serving those statically, some of those are even dynamic routes and that works fine with export const prerender = true.

The issue I'm having though is, I have a backend proxy I only use in development mode. You can see it added to my repro case in this commit: https://github.com/johnnysprinkles/sveltekit_static_dynamic/commit/e91dbdf61d410d817988b06c890513c76bbd6376 In that example it returns a simple string, but in real life is make an HTTP fetch to my actual backend.

With that in place, "npm run build" ends up failing with this message:

> Using @sveltejs/adapter-static
  @sveltejs/adapter-static: all routes must be fully prerenderable (unless using the 'fallback' option — see https://github.com/sveltejs/kit/tree/master/packages/adapter-static#spa-mode). Try adding `export const prerender = true` to your root +layout.js/.ts file — see https://kit.svelte.dev/docs/page-options#prerender for more details
    - src/routes/api/[...rest]
error during build:
Error: Encountered dynamic routes
    at adapt (file:///Users/jpsimons/dev/sveltekit_static_dynamic/node_modules/@sveltejs/adapter-static/index.js:35:12)
    at adapt (file:///Users/jpsimons/dev/sveltekit_static_dynamic/node_modules/@sveltejs/kit/src/core/adapt/index.js:28:8)
    at Object.handler (file:///Users/jpsimons/dev/sveltekit_static_dynamic/node_modules/@sveltejs/kit/src/exports/vite/index.js:488:12)
    at async PluginDriver.hookParallel (file:///Users/jpsimons/dev/sveltekit_static_dynamic/node_modules/rollup/dist/es/shared/rollup.js:22632:17)
    at async Object.close (file:///Users/jpsimons/dev/sveltekit_static_dynamic/node_modules/rollup/dist/es/shared/rollup.js:23709:13)
    at async Promise.all (index 0)
    at async build (file:///Users/jpsimons/dev/sveltekit_static_dynamic/node_modules/vite/dist/node/chunks/dep-db16f19c.js:45667:13)
    at async CAC.<anonymous> (file:///Users/jpsimons/dev/sveltekit_static_dynamic/node_modules/vite/dist/node/cli.js:748:9)

Is there a way to make the "dynamic route" check logic ignore server endpoints?

Reproduction

The repro is in https://github.com/johnnysprinkles/sveltekit_static_dynamic

If you sync the latest version of that, you can "npm run dev" and everything works using the backend proxy. But "npm run build" fails. It seems like adapter static should just ignore any +server.js files.

Logs

No response

System Info

System:
    OS: macOS 12.2.1
    CPU: (8) arm64 Apple M1
    Memory: 141.84 MB / 8.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 18.10.0 - ~/.nvm/versions/node/v18.10.0/bin/node
    npm: 8.19.2 - ~/.nvm/versions/node/v18.10.0/bin/npm
  Browsers:
    Firefox: 105.0.1
    Safari: 15.3
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.80
    @sveltejs/adapter-static: ^1.0.0-next.44 => 1.0.0-next.44
    @sveltejs/kit: next => 1.0.0-next.511
    svelte: ^3.44.0 => 3.50.1
    vite: ^3.1.0 => 3.1.6

Severity

blocking an upgrade

Additional Information

No response

[thegamerx1]

This happens with the skeleton project as well, with just adding adapter static.

[jamesb93]

I get this with a project with no dynamic routes and just a single +page.svelte

[gbkwiatt]

Same same, happens everywhere and it does not take in account any prerender = false or even config.kit.prerender.enabled = false

[dummdidumm]

The issue I'm having though is, I have a backend proxy I only use in development mode. You can see it added to my repro case in this commit: johnnysprinkles/sveltekit_static_dynamic@e91dbdf In that example it returns a simple string, but in real life is make an HTTP fetch to my actual backend.

To clarify: you want to make SvelteKit ignore the endpoints, because after deployment there's an API at the given URL?

This happens with the skeleton project as well, with just adding adapter static.

I get this with a project with no dynamic routes and just a single +page.svelte

This is expected. You need to add export const prerender = true or else nothing is prerendered, as the error message suggests.

Same same, happens everywhere and it does not take in account any prerender = false or even config.kit.prerender.enabled = false

This needs more info. Also, config.kit.prerender.enabled was removed a while ago in favor of setting this inside +layout/page(.server).js.

[gbkwiatt]

The issue I'm having though is, I have a backend proxy I only use in development mode. You can see it added to my repro case in this commit: johnnysprinkles/sveltekit_static_dynamic@e91dbdf In that example it returns a simple string, but in real life is make an HTTP fetch to my actual backend.

To clarify: you want to make SvelteKit ignore the endpoints, because after deployment there's an API at the given URL?

This happens with the skeleton project as well, with just adding adapter static.

I get this with a project with no dynamic routes and just a single +page.svelte

This is expected. You need to add export const prerender = true or else nothing is prerendered, as the error message suggests.

Same same, happens everywhere and it does not take in account any prerender = false or even config.kit.prerender.enabled = false

This needs more info. Also, config.kit.prerender.enabled was removed a while ago in favor of setting this inside +layout/page(.server).js.

The thing is that I have prerender=true in root +layout.js
And all routes I don't want to prerender I have +server.js export const prerender=false but I still get error either saying that it was marked as prerender but it wasn't prerendered or as above all routes must be fully prerenderable

and my +server.js only has a GET method. So I am really confused, as no matter what I do I can't build with adapter-static.
Either I don't umnderstand documentation correctly or ... I don't know

[johnnysprinkles]

That's what I was thinking (first comment). The endpoint in local development is super convenient. Without that I think I'd either have to prefix all my API calls and probably deal with CORS, or else put a proxy in front and split traffic between dev Vite and my real API.

Isn't the idea of prerendering an endpoint sort of nonsensical? Instead of saying "the fact that nonsensical to prerender things exist, you can't use adapter-static" I'm just wondering if it makes more sense to ignore the nonsensical to prerender things.

[Rich-Harris]

I'm lost. You have pages with dynamic data, but you're trying to prerender them?

[gbkwiatt]

I'm lost. You have pages with dynamic data, but you're trying to prerender them?

In my case I am trying not to prerender then but i either get the message with prerender false, that it encouraged dynamic route and I should try setting layout prerender true, but if I set it to true, it says it wont prerender it. So either I've missed something in docs or there is some bugs. Or maybe I am completely missing the point, but with whatever setting, I cant buils with adapter static.

Ive set global +layout.js with prerender true, and tried to set dynamic routes with prerender false. In all honesty I've tried all combinations, and I just can't build with static adapter.

[dummdidumm]

You can't use adapter static and use dynamic endpoints. There is no server running on the backend, so there is nothing that can serve that GET request. You need to use a different adapter for that.

@johnnysprinkles case is different, he wants that endpoint only during dev mode but ignore it when building.

[gbkwiatt]

@johnnysprinkles case is different, he wants that endpoint only during dev mode but ignore it when building.

Well my case is similar, I have 2 environments, one uses node adapter and that node environment builds production with adapter static. So yeah i want to use dynamic ones for node env, but not on production with adapter static.

[johnnysprinkles]

@Rich-Harris Yes, I have pages with dynamic data but since I'm static rendering the whole site, that data would be loaded client-side. You might wonder why I'm not just using an SPA style fallback in that case. Because, I like to prerender the skeleton of each individual page, as much as can be rendered without having any data, to get those appearing instantly before any hydration happens. Better experience, less spinners.

@dummdidumm Correct. It does seems like kind of an edge case I realize. At the moment I think my best workaround is to recursively rename s/+server.js/server.js/ as part of the "build" script step, then rename it back after. (And I thought those plus signs were pointless! Maybe they do have a good use.)

[Rich-Harris]

@gbkwiatt adapter-node will serve prerendered pages too. You probably don't need to use adapter-static separately.

@johnnysprinkles as an aside, it sounds like this will result in flashes of missing data as you navigate around the app — might be better to do the loading in load, but only if browser === true.

How many proxy endpoints are we talking about? Would it make sense to implement them via handle, rather than creating +server.js routes that will fall afoul of the 'this cannot be prerendered' rule?

[gbkwiatt]

@gbkwiatt adapter-node will serve prerendered pages too. You probably don't need to use adapter-static separately.

I am afraid I can't use node on production environment and that's where the problem is. Not sure why it used to be possible and worked fine and now it's not. But that just means I will need some script to remove dynamic routes before using adapter static, but also keep node environment still running. It is a bit of edge case, but I am in a bit of an impass now.

[johnnysprinkles]

@Rich-Harris There's only one, so yeah, turns out I can make it a hook. See latest commit at https://github.com/johnnysprinkles/sveltekit_static_dynamic/commit/96852f58a344951b89c13eaf2cfa2b0d2c1ae72b

I think we should leave this issue open though just because an endpoint leveraging the routing system would be nicer and more elegant.

And yeah, for that aside, I can explore doing the loading in load. Based on this it seems like onMount is a pretty good place to do it though.