Update request type definitions to make platform possibly undefined

[chrskerr]

This PR is to resolve issue #8230 in which the platform object does not match it's types.

event.platform is typed as an empty object by default so I am changing the server response to fallback to this rather than allowing it to be undefined.

An alternative could be to update the types to make platform optional within event.

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. All changesets should be patch until SvelteKit 1.0

[vercel]

@chrskerr is attempting to deploy a commit to the Svelte Team on Vercel.

A member of the Team first needs to authorize it.

[changeset-bot]

🦋 Changeset detected

Latest commit: b3f172c

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

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

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

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
kit	🔄 Building (Inspect)		Dec 20, 2022 at 9:27AM (UTC)

[Rich-Harris]

Thanks for the PR! I think the proposed alternative (making event.platform optional) is a more 'honest' approach — "if platform exists then it takes this shape".

Obviously the real solution is to populate platform in dev as well, but that's a can of worms to open later...

[chrskerr]

No problems :)

I had hoped that this PR would ensure that platform was always an empty object, but I think given the runtime differences between dev and prod builds (due to the invocation of the adapter) updating the types will help avoid mistakes.

Something like the below?

The goal being to allow platform itself to be undefined (this pr) and also to ensure that adapter specific keys are definitely optional.

// packages/kit/types/index.d.ts
export interface RequestEvent<
	Params extends Partial<Record<string, string>> = Partial<Record<string, string>>,
	RouteId extends string | null = string | null
> {
	...
	platform: Readonly<App.Platform>;
}

to:

// packages/kit/types/index.d.ts

export interface RequestEvent<
	Params extends Partial<Record<string, string>> = Partial<Record<string, string>>,
	RouteId extends string | null = string | null
> {
	...
	platform: Partial<Readonly<App.Platform>> | undefined;
}

[dummdidumm]

I think Partial<..> isn't needed here - either the whole platform is defined (in prod), or it isn't (in dev), there's no "something exists, something else doesn't". Each adapter can define what exactly App.Platform contains.

[chrskerr]

Yeah that makes sense to me, I imagine that I should also revert my change to server/index.js as well?

Which would mean that the platform object is either undefined (not supplied by adapter or dev mode), or it is exactly as described by the adapter.

If happy with this approach, then I can update the PR today :)

[Rich-Harris]

thank you!