Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting trailingSlash = "always" in layout with a srr = false page causes 404 errors in prod #13255

Open
peterreeves opened this issue Dec 30, 2024 · 4 comments · May be fixed by #13262
Open
Labels
bug Something isn't working

Comments

@peterreeves
Copy link

peterreeves commented Dec 30, 2024

Describe the bug

I have a project using adapter-static. I've set up the following in my src/+layout.server.js file:

export const prerender = true;
export const trailingSlash = "always";

(Unfortunately the hosting setup I'm using requires trailingSlash set to "always")

If I have a route src/foo/+page.svelte that isn't able to be server side rendered, creating a src/foo/+page.js file and filling it with:

export const ssr = false;

will work fine in dev. But in prod (or using Vite's preview mode) the page 404s. The network inspector says it's failing to fetch something at:

/foo/__data.json?x-sveltekit-trailing-slash=1&x-sveltekit-invalidated=10

This file doesn't exist in the build output, but for some reason the site is asking for it.

To my surprise, this also works for the route page, if it also disables SSR.

Removing the trailingSlash = "always" or the ssr = false options makes the site work again.

Reproduction

Create a blank SvelteKit Project using adapter-static as it's output.

Create a src/+layout.server.js file:

export const prerender = true;
export const trailingSlash = "always";

Create a src/+page.js file:

export const ssr = false;

Run npm run dev. Observe that the page works fine in dev.

Run npm run build and npm run preview. Observe that the page shows a 404 error.

I have created a StackBliz project showing the effect

Logs

No response

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (24) x64 AMD Ryzen 9 5900X 12-Core Processor
    Memory: 16.80 GB / 31.91 GB
  Binaries:
    Node: 22.5.1 - C:\Program Files\nodejs\node.EXE
    npm: 10.9.0 - C:\Program Files\nodejs\npm.CMD
    pnpm: 8.15.5 - ~\AppData\Local\pnpm\pnpm.CMD
  Browsers:
    Edge: Chromium (131.0.2903.86)
    Internet Explorer: 11.0.26100.1882
  npmPackages:
    @sveltejs/adapter-static: ^3.0.8 => 3.0.8
    @sveltejs/kit: ^2.15.1 => 2.15.1
    @sveltejs/vite-plugin-svelte: ^4.0.0 => 4.0.4
    svelte: ^5.16.0 => 5.16.0
    vite: ^5.0.0 => 5.4.11

Severity

serious, but I can work around it

Additional Information

No response

@eltigerchino
Copy link
Member

eltigerchino commented Dec 31, 2024

I'm not able to reproduce the issue by following the reproduction steps or through the Stackblitz example. Can you share another minimal reproduction that reproduces the issue?

@peterreeves
Copy link
Author

Sorry, I think I may have edited the StackBlitz project without realizing it after I posted this issue. I've updated the StackBlitz project again:
https://stackblitz.com/edit/trailing-slash-bug

Observe npm run dev shows the page just fine.
Then npm run build and npm run preview and the page fails with 404.

I've tested this in both Edge and Firefox.

@peterreeves
Copy link
Author

Also, I just realized my reproduction steps in the first post was wrong, it should be a +layout.server.js file. I thought it didn't matter, but the issue doesn't occur if you have a +layout.js file instead (I thought I had tested this both ways, but I guess I maybe missed a step).

@eltigerchino eltigerchino added bug Something isn't working and removed awaiting submitter labels Jan 2, 2025
@eltigerchino
Copy link
Member

eltigerchino commented Jan 2, 2025

Thanks. It seems the issue stems from SvelteKit thinking there's a server load when the trailingSlash option is set in a +page.server or +layout.server file due to this line:

has_server_load: node.server?.load !== undefined || node.server?.trailingSlash !== undefined

Unfortunately, we can't just remove it because it's a fix from #10531 and #10475

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants