feat: move basePath and prerenderedRoutes to the public SSRManifest api

[ottomated]

Cleans up some private API access for adapter-node and adapter-cloudflare. This also will allow adapter-cloudflare to import the manifest only, instead of having to add additional exports to it, helpful for @cloudflare/vite-plugin stuff.

---

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:.

[pkg-svelte-dev]

Install the latest version of @sveltejs/kit from ba0491d:

pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/ba0491d64dbb952e6f1086e655bdaa42875daedd

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/kit/pr/16827

[changeset-bot]

🦋 Changeset detected

Latest commit: ba0491d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages

Name	Type
@sveltejs/kit	Minor
@sveltejs/adapter-vercel	Minor
@sveltejs/adapter-node	Minor
@sveltejs/adapter-cloudflare	Minor

Not sure what this means? Click here to learn what changesets are.

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

[svelte-docs-bot]

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

[Rich-Harris]

Quoting myself from #16464 (comment): I think we should be moving away from adding more stuff to the public manifest, with an eventual goal of getting rid of it entirely. Thoughts?

To expand on 'iterate on that stuff', here's where my head is currently at: I think we can avoid exposing manifest at all to adapter code — rather than having builder.generateManifest(...) we could have something like builder.generateServer(...) that creates a module like this:

export const server = new Server({
  // ...the manifest...
});

The adapter's job is then to create one of these modules for each group of routes, write them to disk wherever it pleases, and use it in the platform glue code:

const server = `${tmp}/${group.name}/index.js`;
const dest = `.my-platform/functions/${group.name}/index.js`;

builder.generateServer(server, {
  routes: group.routes
});

fs.writeFileSync(dest, `
import { server } from '${path.relative(path.dirname(dest), server)}';

server.init({
  env: MyPlatform.getEnv()
});

export default {
  fetch(request, ctx) {
    return server.respond(request, {
      getClientAddress: () => ctx.clientAddress
    });
  }
};
`);

Doing this frees us up to treat the manifest as evolvable implementation detail rather than public API that needs to be maintained, and is just all around a bit neater. (Some adapters do use manifest in their code but not in a way that changes anything. Making the contents of $app/manifest available to adapters would suffice.)

[ottomated]

Quoting myself from #16464 (comment): I think we should be moving away from adding more stuff to the public manifest, with an eventual goal of getting rid of it entirely. Thoughts?

I like it, but we'd need to add manifest as a public property of server (is that what you're thinking?) Then all of the private properties of SSRManifest could be moved to no longer be internal, to allow adapters to type-check on them.

[teemingc]

we'd need to add manifest as a public property of server (is that what you're thinking?)

Might be more about adding the right APIs to the Builder rather than exposing the manifest directly

[ottomated]

Might be more about adding the right APIs to the Builder rather than exposing the manifest directly

adapter-node and adapter-cloudflare access manifest properties: mimeTypes, basePath, appPath, prerenderedRoutes, and assets