adapter static+endpoint / adapter static + refresh page

[dulyas]

Describe the bug

after last npm update after run build everythink is ok on npm run preview but if if deploy my site on hosting and refresh any not main page i got 403/404

also i need POST method on my form with endpoint and after run build on run preview its ok, but after deploy i got 404 on my index.json.js, index.js, api/, api/index.json etc have no idea what to do help pls

Reproduction

npm init svelte@next my-app // select test app
cd my-app
npm install
npm run dev -- --open
npm i @sveltejs/adapter-static
change adapter on svelteconfig
npm run build
npm run preview - everythink is ok
deploy on host - cant refresh pages and not todo app

Logs

No response

System Info

any, any, any

Severity

blocking all usage of SvelteKit

Additional Information

No response

[chvanam]

npm i -D @sveltejs/adapter-static@next maybe to get the latest version of the static adapter?
Otherwise which host are you deploying to?

[Maxim-and-Ko]

the same problem. when the page is reloaded or open it through address bar - it gives 404
When opening the page through the index.html, everything works

[qbunt]

We're seeing this with the next-29 static adapter and '@sveltejs/kit': 1.0.0-next.294_sass@1.49.9+svelte@3.46.4 deploying onto Cloudflare pages. pnpm run preview after build works absolutely fine, but when deployed to CF, we get consistent 404's. I don't see any root level index page inside the build folder when running builds locally.

[qbunt]

@Maxim-and-Ko, @dulyas current build locally outputs

> Using @sveltejs/adapter-static
  You should set `config.kit.prerender.default` to `true` if no fallback is specified
  Wrote site to "build"

adding default: true to the svelte.config.js file does fix this issue

kit: {
    // hydrate the <div id="svelte"> element in src/app.html
    adapter: adapter(),
    prerender: {
      crawl: true,
      enabled: true,
      onError: 'continue',
      default: true
    },

[benmccann]

You may want to try setting trailingSlash: 'always' in case this is the same as #3852

[qbunt]

@benmccann tried that first and had the same 404 result, did that change recently?

[Rich-Harris]

The trailingSlash thing was a separate change that happened a couple of weeks ago (prior to that, prerendering would always generate page/index.html files instead of page.html files, but that means that the majority of static hosts would redirect /page to /page/, so the new behaviour ensures that your URLs are consistent between dev and deploy).

@dulyas you can't use adapter-static if your endpoints have post handlers`. We probably need to make that clearer at build time via an error.

[Maxim-and-Ko]

You may want to try setting trailingSlash: 'always' in case this is the same as #3852

okay, it worked. And what to do with [slug] pages?

[Rich-Harris]

I don't know what it is you're facing @Maxim-and-Ko but you will need to open a separate issue with a reproduction if you want to get help — please don't hijack other people's issues. I would assume that /news/66 isn't being prerendered because the content isn't available at build time, in which case adapter-static is the wrong thing to use. If the content is available at build time then you need to ensure that either a) the crawler can find a link to it, or b) you specify it in config.kit.prerender.entries.

[qbunt]

@Rich-Harris based on current behavior, the default value is required on Cloudflare Pages with a static site, otherwise the index page 404's. Before this, we never had that value in the config file and did not have this issue.

[Rich-Harris]

Right, the behaviour changed. That's why you saw this message:

You should set config.kit.prerender.default to true if no fallback is specified

[qbunt]

yeah I just tried again with a fresh app and see the messaging now. Thanks @Rich-Harris 👍

[Conduitry]

#4287 has been opened to have a more helpful build-time message about using the static adapter with a dynamic app, so I'm closing this issue.

It's hard to pick through all the other unrelated discussions that was happening here, but it sounded to me like it was usage questions, and not reproducible bugs.