$page.url.pathname represented as "//prerender/" when building using the static adapter

[metonym]

Describe the bug

Using the latest versions:

• @sveltejs/kit version 1.0.0-next.211
• @sveltejs/adapter-static version 1.0.0-next.24

In development, $page.url.pathname in routes/index.svelte will correctly be displayed as "/".

However, when building for production using the static adapter, the same route is represented as "//prerender/".

Inspecting build/index.html, the markup has the correct "/" but the script that hydrates the markup has the following:

<script type="module">
  import { start } from "/_app/start-40ff21d5.js";
  start({
    target: document.querySelector("#svelte"),
    paths: { base: "", assets: "" },
    session: {},
    route: true,
    spa: false,
    trailing_slash: "never",
    hydrate: {
      status: 200,
      error: null,
      nodes: [
        import("/_app/layout.svelte-96b29dd0.js"),
        import("/_app/pages/index.svelte-91ca303b.js"),
      ],
      url: new URL("sveltekit://prerender/"),
      params: {},
    },
  });
</script>

Evaluating new URL("sveltekit://prerender/") shows that the URL.pathname is //prerender/.

Workaround

A workaround is to explicitly set kit.ssr or kit.hydrate to false.

Reproduction

https://github.com/metonym/sveltekit-page.url.pathname

Logs

No response

System Info

System:
  OS: macOS 11.4
  CPU: (8) x64 Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
  Memory: 19.40 MB / 16.00 GB
  Shell: 5.8 - /bin/zsh
Binaries:
  Node: 16.13.1 - ~/.nvm/versions/node/v16.13.1/bin/node
  Yarn: 1.22.17 - /usr/local/bin/yarn
  npm: 8.1.2 - ~/.nvm/versions/node/v16.13.1/bin/npm
Browsers:
  Chrome: 96.0.4664.110
  Firefox: 89.0.2
  Safari: 14.1.1
npmPackages:
  @sveltejs/adapter-static: next => 1.0.0-next.24 
  @sveltejs/kit: next => 1.0.0-next.211 
  svelte: ^3.44.0 => 3.44.3

Severity

blocking an upgrade

Additional Information

No response

[musaffar-patel]

I've run into the exact same issue.

I added hydrate: false to svelte.config.js

kit: {
hydrate: false
}

but while the above workaround fixed the pathname issue it broke other functions such as click handlers. So I have tried ssr: false and so far this does not result in any problems as far as I can tell.

[matthewmullin01]

I've found the same with both the nelify and vercel adapters.

Essentially any page that I am prerendering seems to have this issue

[bluwy]

Note: I've tested new URL("sveltekit://prerender/") in a few places. The result of pathname are:

• Node, Safari: /
• Firefox, Chrome: //prerender/

So this behaviour would technically work in Safari, though I'm not sure who's correct here. A easy fix is to have the protocol to be something like http. Apparently, Firefox and Chrome doesn't accept custom sveltekit: protocols

[brittneypostma]

Looks like this is closed and merged, but I'm still experiencing this on sveltesirens.dev. I was programmatically grabbing the title from the pathname, but had to change it due to this bug. I have a console.log running $page.url.pathname where it can still be seen as //prerender/. If you went directly to any route, it was prefaced with //prerender/.
I am also experiencing images not loading as seen below.
If I navigate using the navbar which says /about, I am able to see the image.

[brittneypostma]

Apparently I was missing the forward / before my image there which was causing that error, so ignore that. The //prerender/ bug is still showing in the console though.

[moritzebeling]

I noticed it in version 218 and it seemingly disappeared after upgrading to 225

[moritzebeling]

Well I have to correct myself:

• In version 218 when I visit my deployed production website and use the goto method to manipulate the URL, a new tab opened with a //prerender/... url.
• In version 229 that behaviour disappeared and the URL update worked as intended
• But when I now do a //prerender/ search in the build folder, it matches every prerendered html file:

start({
	target: document.querySelector("#svelte"),
	paths: {"base":"","assets":""},
	session: {},
	route: true,
	spa: false,
	trailing_slash: "never",
	hydrate: {
		status: 200,
		error: null,
		nodes: [
			import("/_app/pages/__layout.svelte-0057c1c3.js"),
			import("/_app/pages/_lang_/__layout.svelte-e41373d5.js"),
			import("/_app/pages/_lang_/index.svelte-5ab6d11c.js")
		],
		url: new URL("http://prerender/de"),
		params: {lang:"de"}
	}
});

[bluwy]

• But when I now do a //prerender/ search in the build folder, it matches every prerendered html file:

This is normal as it's a valid URL. You can paste new URL("http://prerender/de") in the browser console to verify that pathname is /de.

@brittneypostma Can you confirm this is still an issue in the latest SvelteKit version?

[brittneypostma]

Yes, this is same thing I am experiencing on sveltesirens.dev, I have a console.log running the page.url.pathname and it spits out the //pretender/ instead of the expected / route.

[bluwy]

Ah I didn't notice the console.log in production. When I inspect the HTML and search for //prerender, I noticed this in the markup:

import { start } from "/_app/start-297ca0d0.js";
start({
	target: document.querySelector("#svelte"),
	paths: {"base":"","assets":""},
	session: {},
	route: true,
	spa: false,
	trailing_slash: "never",
	hydrate: {
		status: 200,
		error: null,
		nodes: [
			import("/_app/pages/__layout.svelte-f663ade3.js"),
			import("/_app/pages/index.svelte-ba6002e1.js")
		],
		url: new URL("sveltekit://prerender/"),
		params: {}
	}
});

The new URL("sveltekit://prerender/") was there, but in recent versions, this should be new URL("http://prerender/") which fixes the issue. I checked the repo and SvelteKit wasn't updated yet, or was it tested locally?

I tried to spin up the svelte sirens repo locally too, but I'm getting 500 /speakers error while building (adapt stage).

[metonym]

I updated the repro to use the latest SvelteKit (v1.0.0-next.231) and also added console.log($page.url.pathname) to routes/index.svelte. I'm no longer seeing this error.

After building using the static adapter, I see "/" in the console, as expected.

[brittneypostma]

Same here, after updating to latest, this issue seems to have been resolved.

[ollyde]

Also seeing the same issue but with +layout.server.ts using the node adaptor, there seems to be no way to get the original request (which we need to set dynamic api urls)

My issue was closed very fast though, so not sure what to do, this seems like a bug too me

#10586