feat: use read to retrieve prerendered data

[alecbakholdin]

Resolves #15035

This PR is an attempt at hopefully guiding someone in the right direction. I made a best effort to put forward a solution to the issue but ultimately I'm not super confident of the approach here and I'm not knowledgeable enough about the codebase to come up with a better one at this time. Hopefully, someone who knows this area better can take this and run with it, or at least provide some suggestions on how I can improve this more.

This solution solves the problem for cloudflare adapters and locally, but could break other implementations.

Brief Restatement of Problem

when using cloudflare, and likely other adapters, Cloudflare Workers prevents us from making full fetch requests to the same worker, presumably to prevent untraceable infinite call loops? Instead, we're meant to use service bindings like env.ASSETS.fetch().

Solution

1. Replaced the prerendered remote function's fetch call with $app/server's read. (there was already a TODO to allow adapters to inject their own methods here, I thought this might be a step in that direction)
2. Since prerendered routes are stored as files, I added an exception in the $app/server read function to allow prerendered routes as well as server assets found in the manifest

Problems

1. I need help understanding what kinds of implications this could have. It feels like the first change is pretty isolated, tested that CSR and SSR both work now, but I don't know how this plays with other adapters. Help!
2. We don't store the prerendered assets' content lengths, which means that I'm not passing a Content-Length header in the response of the read function. I tried to add the prerendered asset to the manifest._.server_assets object but couldn't quite get there. Help!

---

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

• Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 90f514f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-kit-15037-svelte.vercel.app/

[teemingc]

This should import from an internal path rather a user facing path such as $app/...

[teemingc]

Suggested change

	// TODO adapters can provide prerendered data more efficiently than
	// fetching from the public internet

[teemingc]

It might be better to reimplement read rather than overloading the current implementation.

1. Not all adapters support read so it'll be good if we can also fallback to a regular fetch if the adapter doesn't have support for it.
2. Having the prerendered data added to the server manifest helps adapters such as the Vercel adapter automatically include the server asset in the serverless function bundle (this is different from the public assets that are uploaded separately from the serverless function). Note that this would increase the serverless function size and some platforms have a limit for this. Currently, server assets are recorded via export function find_server_assets(build_data, routes) { while remote function prerender data is simply saved to the public folder via const dest = ${config.outDir}/output/prerendered/${category}/${file};. This should also help determine the correct length rather than how it's implemented now (checks if it exists in prerendered_routes but tries to find the length from server_assets
3. The type would always be json since that's how prerendered data is stored

[teemingc]

Thanks for the PR! I think this is worth pursuing but the concerns I highlighted would need to be addressed. You can also verify the solution by adding tests to each adapter's e2e test suite which should have a SvelteKit app built using the given adapter (we're only missing one for Vercel but we plan to set up some actual deployment mechanism to test against).